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Abstract 

This  resezirch  developed  a  formal  method  for  adding  new  domains  to  Ardiitect,  a 
dommn-oriented  application  composition  system  being  developed  at  the  Air  Force  Institute 
of  Technology  (AFIT)  to  explore  new  software  engineering  technologies.  Using  canonical 
formal  specifications  of  domain  objects,  Architect  rapidly  composes  these  specifications 
into  a  softweire  application  and  executes  a  prototype  of  that  application  as  a  means  to 
demonstrate  its  correctness  before  any  programming  language  specific  code  is  generated. 
Architect  is  implemented  in  the  Software  Refinery  environment,  which  allows  Architect 
to  create  and  mzmip\ilate  object-oriented  specifications.  As  a  psurt  of  this  research  effort, 
domain-oriented  application  composition  systems  were  investigated  in  general,  leading  to 
the  development  of  a  general  method  for  populating  the  knowledge  base  of  systems  of  this 
type.  This  general  population  method  was  then  used  as  a  basis  for  creating  a  specific 
knowledge  base  population  method  for  Architect.  To  validate  this  method,  Architect  was 
populated  with  the  Digital  Signal  Processing  domain.  The  correct  implementation  of  this 
domain  was  verified  by  creating  applications  and  comparing  their  execution  to  expected 
results.  The  addition  of  the  Digital  Signal  Processing  domain  to  Architect  sdso  serves  to 
validate  the  usefulness  and  correctness  of  the  Architect  system. 


A  METHOD  FOR  POPULATING  THE 


KNOWLEDGE  BASE  OF  AFIT’S  DOMAIN- 
ORIENTED  APPLICATION  COMPOSITION  SYSTEM 

I.  Introduction 

1.1  Background 

As  software  development  has  increased  in  both  amount  and  complexity,  problems 
with  cvurrent  software  development  methodologies  have  become  apparent.  Ciarrently,  most 
software  is  developed  in  a  non-formalized  and  haphazard  fashion-often,  a  different  method 
is  used  for  each  software  development  effort.  The  software  developed  is  not  portable- 
current  processes  are  designed  to  get  individual  programs  out  the  door,  not  to  generalize 
or  standardize  groups  of  programs.  Reuse  is  not  widespread-often  the  development  of 
each  program  is  treated  as  a  totally  new  problem  without  consideration  of  work  done  on 
past  programs.  There  is  a  semantic  gap  between  software  developers  emd  the  users  that 
causes  problems  in  communicating  requirements  from  the  users  to  the  developers,  result¬ 
ing  in  softweure  with  errors  and  missing  requirements.  This  gap  occms  because  software 
development  is  done  by  progrzimmers  who  are  trained  in  programming  methods,  but  are 
not  necessarily  familiar  with  the  area  in  whidi  that  the  software  is  being  written.  On  the 
other  hand,  the  experts  in  these  areas  are  often  not  familiar  with  good  software  engineering 
praurtices.  Also,  it  is  an  onerous  task  to  find  amd  correct  errors  in  softwaire  developed  in 
this  faishion,  especiaJly  lairge  bodies  of  code,  madcing  verification  amd  vadidation  extremely 
diflicult. 

Because  of  these  amd  other  problems,  the  softwaure  engineering  community  is  cur¬ 
rently  reseaurching  methods  to  improve  software  engineering,  including  formad  methods 
(such  as  formad  transformation  amd  verification  theories),  decomposition  methods  (object- 
oriented,  etc.),  aurtificiad  intelligence  techniques,  automated  tools  that  incorporate  softwau-e 
development  knowledge,  amd  formadized  reuse  at  both  the  code  amd  specification  level. 
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Figure  1.1  shows  one  such  formal  software  development  method,  which  we  call  application 
composition,  that  incorporates  maay  of  these  methods. 


Figure  1.1  A  Formalized  Software  Development  Method:  Application  Composition 

In  this  formal  softwzure  development  method,  a  domain  expert  analyzes  a  domain, 
captvires  domain  information  and,  along  with  the  software  engineer,  enters  this  information 
into  the  knowledge  beise  in  the  form  of  reusable,  executable  specifications  called  primitives. 
Depending  on  the  methods  incorporated  into  a  particular  application  composition  system, 
these  primitives  may  represent  objects,  functions,  parts  of  a  domain  theory,  or  Domain 
Specific  Software  Architectures  (DSSA)  (8),  among  others.  Included  with  these  primitives 
is  information  that  indicates  how  they  can  be  grouped  together  (composed)  into  applica¬ 
tions.  When  a  sufficient  number  of  these  primitives  have  been  added  to  the  the  knowledge 
base,  the  Application  Designer  can  use  them  to  create  new  applications.  Because  these 
applications  are  developed  in  a  formal  automated  environment,  their  execution  can  be 
simulated.  This  simulation  aids  verification  and  validation  by  allowing  the  application 
designer  to  observe  the  expected  behaviors  of  the  application  and  make  sure  that  the  ap¬ 
plication  meets  the  specified  requirements.  After  the  application  has  been  validated,  it 
cm  be  transformed  into  a  target  Imguage  (such  as  Ada  or  C-l— 1-),  or  possibly  directly  into 
machine  code. 
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The  application  composition  method  possesses  mainy  advantages  over  the  traditional 
software  development  process.  Analyzing  and  storing  domain  information  in  this  manner 
is  significant  because  it  only  needs  to  be  done  once  and  is  accomplished  by  an  expert 
in  the  domain;  some  current  software  development  methods  also  include  a  form  of  this 
emsilysis,  but  it  is  only  done  at  the  application  level  and  is  usually  redone  from  scratch 
for  every  development  effort.  Also,  in  current  methods  this  analysis  is  accomplished  by 
a  softwaire  expert,  not  a  domain  expert  who  is  more  knowledgeable  in  the  domzun  under 
consideration.  Once  the  domain  is  established,  the  reusability  provided  by  the  knowledge 
base  decreases  development  time  dramatically  since  all  the  domain  information  needed 
is  eilready  in  the  system.  This  domain  analysis  portion  of  the  application  composition 
methodology  also  provides  formalization  and  standardization  across  all  applications  in  the 
domain,  enhaincing  application  development,  maintenance,  and  communication  between 
application  designers. 

The  application  composition  method  provides  many  other  advantages.  Validation 
becomes  easier  and  more  complete  because  formal  validation  techniques  can  be  performed 
on  the  application  as  it  is  being  composed,  instead  of  waiting  until  the  final  product 
is  available  for  testing.  This  eeurly  validation  reduces  errors  and  required  maintenance. 
Similarly,  prototyping  capabilities  and  costing  analyses  are  enhanced  by  the  application 
simulation  capability  because  a  “working”  system  can  be  created  without  the  effort  of 
developing  an  executable  program.  Mmntenance  time  is  reduced  because  modifying  a 
specification  (which  is  at  a  higher  level  of  abstraction)  is  less  comphcated  than  changing 
the  low-level  lemguage  code;  additionally,  because  less  maintenance  is  needed  and  the 
maintenance  is  done  at  a  higher  level,  errors  normally  created  during  the  maintenance 
phase  axe  reduced.  Also,  since  the  intended  user  of  the  new  software  can  perform  the 
function  of  the  Application  Designer,  the  requirements  are  more  likely  to  be  met. 

There  are  many  obvious  advEuatages  to  this  new  formal  software  development  method; 
however,  its  use  is  still  limited  because  many  of  the  technologies  and  methods  necessary  to 
implement  this  approach  have  not  been  fully  developed.  Additional  reseEurch  and  testing 
must  be  accomplished  before  this  method  can  be  implemented  on  a  wide-sprezwi  basis. 
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1.2  Problem  Description 


The  Knowledge-Base  Software  Engineering  (KBSE)  group  at  AFIT  has  developed  a 
prototype  application  composition  system,  called  Architect,  to  research  and  test  this  new 
formal  softweire  development  methodology.  Architect  is  a  domain-oriented  software  appli¬ 
cation  composer  that  implements  a  formal  object-oriented  software  development  method 
with  emphasis  on  reusability.  A  simplified,  high-level  conceptual  diagram  of  this  system 
is  shown  in  Figure  1.2.  In  this  figure,  the  square  boxes  are  actuid  Architect  components 
while  the  rounded  boxes  are  processes.  In  Architect,  the  knowledge  base  (described  as  part 
of  the  application  composition  method)  is  called  the  Technology  Base. 


Problem  Statement:  Investigate  amd  implement  a  method  to  populate  the  Tech¬ 
nology  Base  (knowledge  bfise)  in  Architect  and  demonstrate  that  a  more  substantial  domain 
can  be  implemented  in  this  system. 
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Currently,  there  is  no  formalized  method  for  entering  domain  knowledge  into  Archi¬ 
tect’s  Technology  Base  (the  Populate  Technology  Base  process).  This  domain  knowledge 
includes  the  domain  primitives  and  a  dom2un  model,  as  well  as  a  dom2dn-specific  language 
(DSL)  and  primitive  composition  information.  Also,  restrictions  on  the  domain  analysis 
approach  for  developing  this  domain  knowledge  have  not  been  formalized.  Additionally, 
before  this  research  effort,  only  two  relatively  simple  domains  had  been  implemented  (a 
pedagogical  domadn  called  “widgets”  and  the  digital  logic  domain).  The  purpose  of  our 
research  was  to  identify  and  describe  restrictions  for  methods  to  gather  the  domain  knowl¬ 
edge  (dommn  analysis)  and  develop  a  formal  method  to  insert  this  domain  information 
into  the  Architect’s  Technology  Base  (domain  implementation)  so  that  it  can  be  used  to 
create  applications.  Also,  while  validating  this  method,  we  demonstrated  that  a  more 
substantial  domeiin  can  be  implemented  in  Architect  so  that  the  system  can  be  used  to 
compose  applications  in  this  more  complex  domain. 

1.3  Scope 

This  thesis  effort  concentrated  only  on  the  Populate  Technology  Base  process  for 
Architect-there  were  severed  other  concmrent  research  efforts  involving  Architect  that  in¬ 
tersected  with  this  one.  These  efforts  involved  improving  the  visual  interface  /citejay, 
deriving  a  domain  architecture  model  (12),  implementing  the  Saved  Technology  Beae  in 
ein  object-oriented  database  (7),  eidding  an  application  executive  capability  (45),  and  im¬ 
plementing  an  event-driven  domain  (41). 

Because  eeich  of  these  efforts  involved  independent  modifications  to  Architect,  it 
would  have  been  intractable  to  use  the  most  ciurent  version  as  a  basis  for  our  research. 
Thus  our  rese£u:ch  (as  well  as  the  others)  was  accomplished  using  Architect  as  it  existed 
(with  some  minor  changes)  at  the  beginning  of  this  thesis  effort  (nonetheless,  every  effort 
was  meide  to  ensure  that  all  our  work  would  be  compatible).  The  one  exception  is  that 
we  did  incorporate  the  changes  made  as  a  result  of  Cossentine’s  research  (as  well  as  the 
changes  resulting  from  this  research  effort).  Because  of  this  independence,  the  knowledge 
base  population  method  developed  in  our  research  does  not  include  some  of  the  changes 
incorporated  in  these  concurrent  research  efforts.  For  example,  this  research  effort  was 


1-5 


not  integrated  with  the  database  implementation  of  the  Saved  Technology  Base  (imple¬ 
mented  by  Cecil  and  PuUenkamp);  however,  this  change  from  tiles  to  a  database  only  affects 
the  form  of  the  Populate  Technology  Base  process,  not  the  fimctionality.  It  should  be  a 
simple  transformation  to  take  the  results  of  this  thesis  and  apply  them  to  the  database 
implementation  of  the  Saved  Technology  Base.  Also,  the  time-  and  event-driven  execution 
capabilities  added  by  Welgan  requires  additional  timing  information  be  added  to  the  do¬ 
main;  collecting  and  implementing  this  information  will  need  to  be  added  to  our  method 
at  a  future  time,  but  this  should  be  a  minor  change. 

Due  to  time  restrictions,  only  one  domain  was  implemented  as  a  pent  of  our  research. 
Therefore,  we  validated  our  Technology  Base  Population  method  using  only  this  imple¬ 
mentation.  Although  every  effort  was  made  to  generalize,  some  minor  changes  may  need 
to  be  made  to  this  method  as  other  domains  with  different  features  are  implemented. 

This  research  included  some  minor  changes  to  the  capabilities  of  Architect  itself. 
Because  the  implemented  domain,  Digital  Signal  Processing  (DSP),  weis  more  complex 
than  the  previously  implemented  domains,  some  extensions  to  the  already  implemented 
capabilities  need  to  be  made.  For  example,  before  this  work  Architect  required  that  com¬ 
munication  between  primitives  consist  only  of  passing  simple  data  types;  the  DSP  domain 
required  that  more  complex  types  be  added  (see  Chapter  V).  These  changes  were  imple¬ 
mented  to  make  it  possible  to  implement  and  use  the  DSP  domain. 

Finally,  the  first  portion  of  this  research  (described  in  Chapters  n  and  III)  were 
developed  jointly  with  Raleigh  Sandy.  His  work  involved  populating  another  application 
composition  system  called  Automatic  Programming  Technologies  for  Avionics  Software 
(APTAS). 

1.4  Approach 

The  following  approach  was  used  to  reach  the  objectives  (outlined  in  the  problem 
statement)  of  this  thesis: 
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•  Review  current  literature.  The  results  of  this  review  are  presented  in  Chapter  11. 
While  we  found  much  information  on  domain  analysis,  we  found  little  information 
on  specific  domain  implementation  methods  and  techniques. 

•  Develop  a  generic  knowledge  base  population  methodology.  Part  of  this  effort  re¬ 
quired  us  to  develop  a  description  of  a  generic  application  composition  system  to 
define  the  framework  for  the  generic  population  methodology.  The  first  few  sections 
of  Chapter  III  present  this  generic  application  composition  system,  while  the  later 
sections  expormd  upon  our  generic  knowledge  base  popiUation  methodology. 

•  Instantiate  the  developed  generic  knowledge  base  population  methodology  for  Ar¬ 
chitect.  Because  the  methodology  developed  in  Chapter  III  is  generic,  it  must  be 
instantiated  for  a  particular  application  composition  system  before  it  can  be  used. 
Chapter  IV  shows  our  instantiation  of  this  methodology  for  Architect. 

•  Implement  a  domain.  To  validate  the  population  method  instantiated  in  Chapter  IV, 
we  used  it  to  populate  Architect  with  the  Digital  Signal  Processing  (DSP)  domain. 
This  domain  implementation,  along  with  developing  some  DSP  applications,  also  met 
the  objective  of  demonstrating  that  a  more  substantial  domain  could  be  implemented 
and  used  in  Architect.  The  results  of  this  implementation  and  how  the  domain  was 
validated  are  discussed  in  Chapter  V. 

•  Identify  recommendations  and  conclusions.  Several  reconunendations  for  improving 
Architect  and  for  further  research  were  identified  during  our  thesis  effort;  the  more 
important  ones  are  discussed  in  Chapter  VI.  Also,  our  general  conclusions  drawn 
from  this  research  effort  zure  discussed  in  this  chapter. 

This  thesis  also  includes  several  appendices.  Appendix  A  specifies  in  detail  the 
dommn  knowledge  required  to  implement  a  domain  in  Architect.  Appendix  B  presents 
some  example  DSP  applications.  Appendix  C  summeurizes  the  conventions  used  for  the 
Technology  Base  files  in  Architect.  Appendix  D  list  the  features  identified  during  this 
research  for  possible  incorporation  into  futmre  versions  of  Architect.  Finally,  Appendix  E 
explains  how  to  get  copies  of  the  code  created  as  a  part  of  this  research. 
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II.  Literature  Reviev?- 

2.1  Introduction 

Many  researchers  are  studying  methods  to  encapsulate  knowledge  needed  for  software 
engineering  into  reusable  models.  They  have  proposed  ideas  to  improve  knowledge-based 
software  engineering  and  shorten  the  gap  between  software  and  hardware  system  develop¬ 
ment.  Some  of  this  research  is  directly  related  to  our  knowledge  base  population  problem. 

The  technology  involved  in  the  effective  modeling  of  application  domains  is  very  im¬ 
portant  to  the  success  of  knowledge-based  software  engineering.  Software  engineers  must 
develop  formal  knowledge  acquisition  processes  that  solve  the  knowledge  base  population 
problem.  Section  2.2  reviews  ideas  we  found  useful  in  our  research  from  current  literature 
in  the  areas  of  domain  analysis  and  domain  modeling.  Both  domain  analysis  and  domain 
modeling  focus  on  the  effective  modeling  of  application  domains,  ‘^here  is  a  strong  rela¬ 
tionship  between  [domain  analysis]  and  knowledge  acquisition.  Building  a  knowledge  base 
and  defining  heuristics  for  an  expert  system  are  basically  the  same  problems  as  [domain 
analysis]”  (13). 

Systematic  reuse  is  another  topic  that  supports  knowledge-based  software  engineer¬ 
ing.  Arango  defines  systematic  reuse  as  an  activity  “in  which  information  is  systematically 
acquired  and  reused  in  software  construction  tmder  the  control  of  some  management  guide¬ 
lines  and  costing  models”  (4:84).  The  knowledge  base  must  support  the  code  generation 
component  of  a  knowledge-based  software  engineering  system  by  providing  a  library  of 
reusable  software  specifications  or  implementations.  Section  2.3  reviews  ideas  we  exam¬ 
ined  in  the  2urea  of  systematic  reuse. 

There  is  a  clas9  of  knowledge-based  software  engineering  systems  known  as  appli¬ 
cation  composition  systems  that  employ  techniques  like  automatic  code  generation  and 
formal  methods  to  transform  specifications  into  executable  code.  Because  both  Architect 
emd  APTAS  fall  into  this  class  of  systems,  we  studied  the  characteristics  of  application 
composition  systems.  Our  study  focused  on  the  application  composition  process  and  the 

^This  chapter  was  co-written  with  Raleigh  Sandy  and  also  i^>pear8  in  (35). 
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knowledge  bzise  structures.  Section  2.4  describes  the  composition  process  and  knowledge 
base  structures  of  severid  application  composition  systems. 

Several  terms  require  definition  before  we  begin  our  review  of  the  related  research. 
We  have  already  used  the  term  application  domeun  that  we  define  as  “a  coherent  set 
of  systems  that  exhibits  common  features  and  functionality  across  existing  and  proposed 
insteinces”  (28).  Information  occurring  within  the  scope  of  an  application  domain,  such 
as  functional  behaviors  and  parameters,  is  considered  domain  knowledge.  The  term 
domain  ansdysis  was  first  introduced  by  Neighbors  as  “the  activity  of  identifying  objects 
and  operations  of  a  class  of  similar  systems  in  a  particular  problem  domain”  (26).  Prieto- 
Diaz  later  defined  domain  analysis  as  the  process  where  “information  used  in  developing 
software  systems  is  identified,  captured,  and  organized  with  the  purpose  of  making  it 
reusable”  (31:47). 

2.2  Domain  Analysis 

Domain  analysis  is  the  first,  and  probably  most  important,  step  in  adding  new  in¬ 
formation  to  a  knowledge  base.  Domain  analysis  was  originally  adopted  as  a  process  to 
automate  several  aspects  of  software  development  including  specification  analysis,  verifi¬ 
cation,  and  application  generation  (4:82).  Early  research  into  domain  analysis  uncovered 
the  importance  of  organizing  domain  knowledge  into  reusable  components.  Researchers 
learned  that  identifying  specific  knowledge  to  reuse  through  domain  analysis  was  no  easy 
task.  Neighbors  discovered  that  “the  key  to  reusable  software  is  captured  in  domain  anal¬ 
ysis  in  that  it  stresses  the  reusability  of  analysis  and  design,  not  code”  (27)  and  later 
proposed  a  domain  analysis  method  called  DRACO.  Other  researchers  have  also  proposed 
domain  analysis  approaches,  and  we  summarize  some  of  these  in  the  following  paragraphs. 

Prieto- Diaz  (32)  proptraed  the  data  fiow  model  shown  in  Figure  2.1  that  represents  his 
domain  analysis  approach.  In  his  model,  the  domain  expert  (a  knowledgeable  person  in  that 
particular  field)  and  domain  analyst  (a  person  with  training  and  experience  in  analyzing 
domains)  identify  and  select  the  domiun  knowledge.  Possible  sources  for  domain  knowledge 
include  expert  £idvice,  customer  siirveys,  technical  literature,  and  existing  implementations, 
as  well  as  current  and  future  requirements.  The  domain  analyst  then  assists  the  domain 
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EXISTINQ 


Figure  2.1  Domain  Analysis  Approach  Proposed  by  Prieto-Diaz  (32:67). 


expert  in  abstracting  and  encapsulating  the  collected  domain  knowledge  into  a  subset  of 
the  expected  outputs  (i.e.,  domain  model,  domain  language,  domain  taxonomy),  as  well  as 
domain  standsurds  and  reusable  components.  The  entire  approach  is  implicitly  iterative. 

Arango  based  his  view  of  domain  analysis  on  “the  systematic  and  incremental  ap¬ 
proximation  to  a  definition  of  an  ontology  and  semantics  for  a  problem  domain”  (4:83).  He 
proposed  an  operational  definition  of  domain  analysis  focxised  on  a  reuse-based  task  (4:83): 
Given: 

1.  a  partial,  nonformal  description  of  a  problem  domun 

2.  a  model  of  a  reuser  as  a  learning  system 
Find:  a  systematic  method  to 

1 .  identify  information  in  the  problem  domun  which,  if  available  to  the  retiser 
in  appropriate  form,  would  allow  it  to  attain  a  specified  level  of  perfor¬ 
mance, 

2.  capture  the  information  identified  as  relevant,  and 

3.  evolve  the  acquired  information  to  enhance  or  maintain  the  performance 
of  a  reuser. 

The  domain  analysis  results  in  a  model  of  the  application  domain.  As  vdth  the  approach 
proposed  by  Prieto-Diaz,  this  approach  identifies  and  collects  reusable  domain  knowledge. 
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However,  Arango’s  approach  also  compares  the  performance  of  the  reuse-based  task  to  a 
desired  performance  level.  The  domain  analysis  works  to  improve  the  reuse-based  task  until 
it  reaches  the  desired  performance.  Therefore,  Arango  modeled  the  reuser  as  a  learning 
system  where  improvements  to  performance  correspond  to  subsequent  iterations  of  domain 
analysis. 

McC2un  (25)  proposed  a  domain  analysis  approach  consisting  of  two  separate  tasks. 
The  first  task,  application  domain  analysis,  identifies  a  hierarchy  of  components  and  their 
associations.  Application  domain  analysis  is  basically  the  same  as  other  domain  analysis 
approaches  studied.  This  task  has  three  activities:  define  reusable  entities,  define  reusable 
abstractions,  and  perform  classification  of  reusable  abstractions.  The  second  task,  com¬ 
ponent  domain  analysis,  defines  the  individual  component  behaviors  and  requirements. 
This  task  has  four  activities  to  define  component  interfaces,  constraints,  algorithms,  and 
customization  requirements.  McCun’s  approach  is  different  from  other  domain  analysis 
approaches  by  his  explicit  inclusion  of  a  component  domain  analysis  task. 

Kang  and  others  (18)  proposed  a  domain  analysis  approach  called  Feature-Oriented 
Domain  Analysis  (FODA).  The  approach  identifies  prominent  features  (similarities)  and 
distinctive  features  (differences)  of  software  systems  within  an  application  domain.  The 
features  also  define  mandatory,  optional,  and  alternative  characteristics  of  software  systems 
in  the  domain.  Unlike  the  other  domain  analysis  approaches  we  have  summarized,  the  re¬ 
searchers  described  FODA  in  sufiicient  detail  to  use  on  large  domain  walysis  projects  (ones 
with  several  domain  walysts).  However,  this  depth  of  detail  can  restrict  the  applicability 
of  the  approach. 

The  Domeun  Analysis  Working  Group  Report  (39)  described  two  domain  analysis 
approaches.  The  first  approach  lists  the  common  steps  found  in  other  domain  analysis 
approaches: 

1.  Define  Domain  Analysis 

2.  Identify  and  scope  the  domain 

3.  Select  a  representative  set  of  systems  to  study 

4.  Gather  inputs  for  the  domain  analysis 

5.  Perform  feature  analysis  at  the  requirements  level 
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6.  Analyze  separability,  selectability,  and  trade-oSs  of  fesitiures 

7.  Select  an  implementation  technology 

8.  Implement  and  validate  products  in  phases 

9.  Deliver  products  of  domain  analysis 

However,  they  give  no  real  explanation  of  how  a  domain  analyst  accomplishes  these  steps. 
They  give  more  detail  for  the  second  approach: 

1.  Acqmre  knowledge 

2.  Perform  high-level  functional  analysis  (top-down) 

3.  Identify  objects  and  operators  (bottom-up) 

4.  Define  domain  models  and  architecture 

A  different  view  of  domsun  analysis  wets  proposed  by  Iscoe  (14).  He  focused  on  the 
results  of  the  domain  analysis  rather  than  a  specific  approach  or  the  inputs  to  the  domain 
analysis.  He  suggested  the  problem  was  *^0  create  a  model  for  domain  knowledge  that 
is  general  enough  to  be  instantiated  in  several  domains”  (15:299).  His  approach  involved 
developing  levels  of  “meta-modeb”  that  a  domain  analyst  uses  to  capture  the  information 
of  a  particular  application  domain.  Modeb  consist  of  objects  and  their  attributes,  along 
with  the  operations  performed  upon  those  objects.  This  approach  had  two  distinct  charac¬ 
teristics:  (1)  attributes  and  operations  are  defined  in  terms  of  their  imderlying  scales  and 
(2)  object  classes  use  multiple  inheritance,  bcoe’s  approach  to  domain  analysis  is  known 
as  domsdn  modeling. 

Domain  modeling  is  a  subset  of  domain  analysis.  It  is  a  formal  approach  to  capturing 
domain  knowledge  into  a  specific  form  that  results  in  a  defined  knowledge  structure  called  a 
domain  model.  We  define  domsun  modeling  as  the  process  of  organizing  and  encapsulat¬ 
ing  information  within  an  application  domain  into  a  predefined  knowledge  struct\ire.  The 
structure  for  a  domain  model  depends  on  the  specific  application  domain  being  modeled 
as  well  as  the  domain  analysis  approach  applied. 

Prieto-Diaiz  suggested  that  the  structure  of  domain  modeb  “range  in  level  of  com¬ 
plexity  and  expressive  power  firom  a  simple  domain  taxonomy  to  functional  modeb  to 
domain  languages”  (31:51-52).  He  defines  a  domain  language  as  “a  collection  of  rules  that 
relate  objects  and  functions  and  which  can  be  made  explicit  and  encapsulated  in  a  formal 
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language  and  further  used  as  a  specification  language  for  the  construction  of  systems  in 
that  domain”  (32:66).  Arango  suggested  that  a  domain  language  documents  a  “shared 
paradigm  [that]  is  a  precondition  for  domain  analysis”  (4:82). 

Neighbors  developed  a  domain  modeling  approach  with  his  DRACO  system  (27), 
one  of  the  first  systems  to  specifically  employ  domain  languages  zmd  domain  models.  His 
approach  involved  a  hierarchy  of  domains  consisting  of  different  levels  of  abstraction.  Do¬ 
mains  at  the  highest  level  of  abstraction  are  called  application  domains.  Domains  at  the 
lowest  level  of  abstraction  model  conventional  programming  languages  and  are  called  ex¬ 
ecutable  domains.  Those  domains  in  between  are  called  modeling  domains.  Application 
domains  span  several  modeling  domains.  A  domun  language  defines  the  external  syntax  of 
an  application  domain.  The  domain  language  semantics  are  written  in  Backus-Naur  form 
and  augmented  with  control  mechanisms. 

The  domain  analysis  approjiches  we  have  described  above  are  a  sample  of  those 
approaches  published.  The  software  engineer  has  many  options  for  using  or  modifying 
an  existing  approach.  Wartik  and  Prieto-Diaz  (43)  presented  a  strategy  for  comparing 
different  domain  analysis  approaches  that  included  the  following  criteria: 

•  definition  of  “domain" 

•  determination  of  problems  in  the  domain 

•  permanence  of  domain  smalysis  results 

•  relation  to  the  software  development  process 

•  focus  of  analysis 

•  paradigm  of  problem  speu:e  modeb 

•  purpose  and  nature  of  domain  models 

•  approach  to  reuse 

•  primary  product  of  domain  development 

Softwzire  developers  can  use  these  criteria  to  choose  a  domain  analysis  approach  that  meets 
their  objectives  and  is  within  their  current  resources. 
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2.S  Systematic  Reuse 

Wartik  and  Prieto-Diaz  also  described  three  categories  of  reuse:  ad  hoc,  opportunis¬ 
tic,  and  systematic  (43).  Ad  hoc  reuse  is  reuse  without  any  formal  reuse  method.  Op¬ 
portunistic  reuse  is  a  software  development  process  with  methods  to  identify  the  types  of 
reusable  components,  when  to  use  them,  and  where  they  might  be  foimd.  Systematic  reuse 
is  a  software  development  process  with  methods  to  define  and  construct  reusable  compo¬ 
nents.  They  suggested  that  a  software  development  process  could  not  realize  systematic 
reuse  without  including  the  role  of  domain  analysis. 

The  success  of  knowledge-based  software  engineering  systems,  such  as  application 
composition  systems,  depends  on  the  practice  of  systematic  reuse.  Prieto-Diaz  suggested 
that  domain  analysis  could  realize  systematic  reuse  by  successfully  “deriving  common 
architectures,  generic  models  or  specialized  languages  that  substantially  leverage  the  soft¬ 
ware  development  process  in  a  specific  problem  area”  (31:47).  He  provided  an  example 
of  how  domain  analysis  might  fit  into  the  softwtire  development  process  (shown  in  Fig¬ 
ure  2.2).  Prieto-Diaz  claimed  that  this  concept  could  support  several  methods  of  software 
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Figtu-e  2.2  Domain  Analysis  and  Software  Development  (31:52). 
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development  other  than  the  waterfall  model.  He  called  this  concept  a  reuse  infrastruc¬ 
ture  emd  stated: 

Domain  models,  in  a  variety  of  forms,  support  (i.e.,  control)  the  different  phases 
of  software  development.  Reusable  resources  are  selected  amd  integrated  in  the 
new  system.  Reuse  data  is  then  collected  and  feedback  to  domain  analysis  for 
refining  the  models  and  for  updating  the  library.  As  developed  systems  become 
existing  systems  they  are  also  used  to  refine  the  reuse  infrastructure  (31:52). 

Neighbor’s  DRACO  system  generates  software  systems  from  abstract  specifications 
using  its  hierarchy  of  domains.  A  specification  begins  in  an  application  domain  and  gets 
refined  by  the  system  through  modeling  domains  until  it  can  be  implemented  using  an 
execution  domain  containing  reusable  components. 

Reusable  components,  like  those  in  DRACO’s  execution  domains,  are  very  important 
to  systematic  reuse.  The  reusable  components  must  be  constructed  using  some  consistent 
structure  called  a  software  architectme.  Software  architectures  define  a  consistent  compo¬ 
nent  structure  and  also  define  how  to  compose  applications  using  a  domain’s  components. 
Researchers  at  the  Software  Engineering  Institute  have  studied  systematic  reuse  and  have 
developed  a  software  architecture  called  the  Object  Connection  Update  (OCU)  model  (20). 
Figiure  2.3  shows  a  subsystem  in  the  OCU  architecture.  Applications  are  composed  of  at 


Figure  2.3  An  OCU  Subsystem  (20:18). 


least  one  subsystem  imder  the  control  of  an  application  executive.  Subsystems  consist  of 
imports,  exports,  a  controller,  and  objects.  Objects  consist  of  inputs,  outputs,  and  update 
functions.  Gool  (12)  smnmarizes  the  OCU  model  as  well  as  several  other  documented 
software  architectmres. 
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2-4  Application  Composition  Systems 

Both  domain  aneilysis  {ind  systematic  reuse  play  important  roles  in  knowledge-based 
software  engineering  systems,  especially  in  the  class  of  application  composition  systems. 
There  eire  several  application  composition  systems  in  use  today.  Anderson  (3),  Ran- 
dour  (33),  and  Weide  (44)  developed  the  initial  version  of  Architect,  which  is  an  application 
composition  system  that  implements  the  OCU  software  architecture.  In  this  system,  do¬ 
main  information  is  captured  in  reusable  objects  at  the  specification  level.  Along  with 
these  reusable  objects  is  information  specifying  a  domain-specific  language  (DSL)  and  vi¬ 
sualization  specification  language  (VSL).  An  Application  Specialist  (the  person  creating 
the  software  system,  called  an  application)  composes  applications  by  either  entering  a  tex- 
tuzd  specification  using  the  DSL  or  by  visually  manipulating  icons  specified  by  the  VSL. 
The  Architect  system  is  undergoing  further  study  at  the  AFIT  (see  research  by  Gool  (12), 
Cossentine  (9),  Welgan  (45),  and  Waggoner  (41)). 

The  Lockheed  Software  Technology  Center,  under  contract  with  the  United  States 
Air  Force,  prototyped  an  application  composition  system  (17).  This  system,  called  AP- 
TAS,  “automatically  synthesizes  executable  code  from  high-level  tracking  system  specifi¬ 
cations”  (17:1).  APTAS  generates  applications  through  the  support  of  its  Tracking  Tax¬ 
onomy  amd  Coding  Knowledge  Base.  The  system  uses  a  software  architecture  enforced  by 
the  knowledge  bjise  structure;  however,  there  is  no  method  defined  to  store  information 
(on  existing  or  new  domains)  into  its  knowledge  base  (see  research  by  Sandy  (35)). 

Several  other  application  composition  systems  exist.  Some  of  these  include  the 
Kestrel  Interactive  Development  System  (KIDS)  developed  at  Kestral  Institute  (36),  the 
Khoros  system  developed  at  the  University  of  New  Mexico  (40),  and  the  Intelligent  Design 
Aid  (IDeA  system)  developed  at  the  University  of  Illinois  (23). 

2.5  Summary 

Software  reuse  has  come  a  long  way  from  ad  hoc  reuse  of  low-level  code.  The  reuse 
of  high-level  abstractions  capturing  domain  knowledge  has  become  a  reality  through  tech¬ 
nologies  like  domain  analysis  and  domain  modeling.  Software  architectures,  combined 
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with  domun  analysis,  have  made  it  possible  for  researchers  to  build  software  development 
systems  that  practice  systematic  reuse  of  both  low-level  code  and  high-level  abstractions. 
Application  composition  systems,  like  Architect  and  APTAS,  have  shown  that  the  users 
themselves  can  develop  their  own  software  systems  in  a  familiar  language  and  environment. 
Ongoing  research  in  dommn  analysis  and  systematic  reuse  will  provide  more  insight  in  the 
development  of  more  operational  application  composition  systems  juid  modeling  more  ap¬ 
plication  domains.  These  advances  promise  to  improve  the  software  development  process 
drastically. 
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III.  Knowledge  Base  Population  Methodology 

S.  1  Introduction 

Many  researchers  have  envisioned  software  development  evolving  from  the  art  of 
hand-writing  code  to  the  engineering  discipline  of  combining  and  specializing  reusable 
components.  One  such  researcher,  Michael  Lowry  (22:630),  envisioned  Knowledge-Based 
Software  Engineering  environments  that  automate  software  reuse  using  domain  knowledge 
captured  through  domain  analysis.  The  KBSE  research  group  at  AFIT  is  developing  formal 
methods  to  implement  the  automated  reuse  that  Lowry  envisioned  in  the  above  paragraph. 
The  group’s  work  is  based  on  several  of  Lowry’s  premises.  This  thesis  is  part  of  the 
group’s  work,  and  it  is  focused  primarily  on  how  to  capture  the  reusable  components  that 
Lowry  described  into  an  automated  software  development  system  (i.e.,  how  to  populate 
the  system’s  knowledge  base). 

This  chapter  proposes  a  general  process  that  can  be  tsdlored  to  populate  the  knowl¬ 
edge  bases  of  a  particular  class  of  software  development  systems.  Section  3.2  defines  the 
particular  class  of  software  development  systems.  Section  3.3  presents  our  view  of  domain 
models  and  their  corresponding  knowledge  base  representations.  Section  3.4  describes  the 
domeiin  anadysis  methods  that  we  found  helpful  in  developing  our  process.  We  use  these 
methods  in  Section  3.5,  along  with  our  system  definition  and  domain  model  view,  to  de¬ 
velop  a  generad  process  to  popidate  a  system’s  knowledge  base.  Finally,  in  Section  3.6, 
we  support  the  development  of  a  “general”  process  and  define  several  constraints  to  its 
implementation. 

3.2  Generic  Domain-Oriented  Application  Composition  System 

We  developed  a  knowledge  base  population  process  for  a  specific  cleiss  of  softwsure  de¬ 
velopment  systems.  There  are  several  characteristics  that  distinguish  this  class  of  systems. 
Each  system  has  a  knowledge  base  and  a  process  to  compose  applications.  The  knowl¬ 
edge  base  stores  reusable  components.  Applications  are  specified  using  these  components. 
Users  can  modify,  save,  and  medntzdn  applications  through  the  composition  process.  Also 

’This  chapter  was  co-written  with  Raleigh  Sandy  and  also  appears  in  (35). 
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through  the  composition  process,  users  can  simulate  the  execution  of  application  (before 
code  is  created),  translate  them  to  some  external  form  (i.e.,  synthesize  code),  and  execute 
them  outside  the  system.  These  characteristics,  including  the  ability  to  synthesize  exe¬ 
cutable  code,  describe  the  class  of  application  composition  systems.  However,  our  class 
of  systems  has  a  knowledge  base  that  must  be  organized  into  application  domains  in  an 
object-oriented  fashion.  Therefore,  we  refer  to  this  class  of  systems  as  Domain-Oriented 
Application  Composition  Systems  (DOACS). 

There  are  several  advantages  to  this  type  of  system.  The  most  important  advan¬ 
tage  is  systematic  reuse.  Reuse  is  not  limited  to  the  code  level,  but  occurs  at  all  levels, 
primarily  at  the  specification  level.  Maintenance  also  occmrs  at  the  specification  level  in¬ 
stead  of  at  the  more  difficult  code  level.  The  application  composition  process,  with  its 
ability  to  simulate  specification  behaviors,  provides  an  ideal  environment  to  develop  rapid 
prototypes.  This  type  of  system  can  also  provide  the  powerful  capability  of  creating  sys¬ 
tems  within  a  graphical  environment.  The  user  works  with  the  components  and  does  not 
have  to  possess  expert  knowledge  of  the  domain  (e.g.,  specific  algorithms).  A  user  does 
not  need  tradition^  programming  knowledge  to  create  new  applications,  nor  to  maintain 
existing  applications,  because  the  system  automatically  generates  applications  from  their 
specifications.  Users  csm  possibly  choose  between  different  hardware  platforms  and  pro¬ 
gramming  Izinguages  when  generating  code.  Finally,  these  systems  could  automate  the 
“housekeeping”  chores  (e.g.,  configiuration  management)  so  users  cein  concentrate  on  the 
more  important  task  of  application  specification. 

It  is  important  to  make  the  distinction  between  domain-oriented  and  domain-specific 
application  composition  systems.  A  domain-specific  system  can  be  used  to  compose  appli¬ 
cations  in  only  one  domain  and  new  domains  cannot  be  euided.  A  domeiin-oriented  system 
can  be  used  to  compose  applications  in  any  dom^un  implemented  in  that  system  and  more 
domains  can  be  culded.  While  there  are  similarities  between  these  two  types  of  systems,  the 
fact  that  domain-specific  systems  contain  only  one  domain  greatly  simplifies  the  creation  of 
the  system  and,  of  comrse,  nullifies  the  problem  of  knowledge  base  population  since  the  do- 
m2Lin  information  is  integrated  into  the  system  when  it  is  built.  Although  domain-specific 
systems  are  limited  to  one  domain,  the  creators  of  the  system  are  able  to  take  advantage 
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of  the  features  of  that  particular  domain  when  designing  the  system  (e.g.,  the  system  can 
be  custom  tailored  around  the  architecture  that  best  fits  that  particular  domain).  Because 
of  this,  domain-specific  systems  have  an  advantage  over  domeun-oriented  systems  in  ease 
of  composition  and  capabilities  in  that  particular  domain.  However,  it  is  not  practical 
to  build  domain-specific  systems  for  every  application  domain.  Due  to  their  modularity, 
it  is  easier  to  update  domain-oriented  systems  with  new  softw2ure  engineering  techniques. 
Also,  only  one  system  has  to  be  updated  to  take  advantage  of  any  new  technique  for  many 
domains  as  opposed  to  updating  several  domain-specific  systems  (it  would  be  a  significant 
effort  to  update  eeich  system  separately). 

Figure  3.1  contains  the  major  cheuracteristics  of  our  generic  DOACS  (G-DOACS).  We 


System  Requiraneols 


have  used  rounded  boxes  to  represent  processes  and  subprocesses  (e.g..  Compose  Appli¬ 
cations  and  Create),  regular  boxes  to  represent  physical  structures  (e.g..  Knowledge 
Base),  and  ovals  to  represent  the  roles  of  the  people  involved.  Notice  that  we  have  also 
included  another  important  characteristic  to  the  G-DOACS  definition,  the  addition  of  a 
Populate  Knowledge  Base  process  that  performs  the  actu2d  knowledge  base  population. 
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3.2.1  Compose  Applications.  An  Application  Specialist  uses  the  Compose 
Applications  process  to  create,  modify,  and  validate  (through  simulation)  software 
plications.  The  application  can  then  be  transformed  into  executable  code.  The  specific 
methods  to  accomplish  this  process  may  vary  from  one  DOACS  to  another. 

In  general,  the  Application  Specialist  creates  an  application  by  choosing  compo¬ 
nents  from  a  domain-specific  component  library,  specifies  how  those  components  connect 
together,  £ind  declares  any  necessary  processing  information.  The  Application  Specialist 
does  not  add  any  new  functionality  (i.e.,  no  new  code),  but  does  specify  a  component’s 
particular  functionality  by  setting  various  component  attributes.  The  ability  to  specify 
components  from  several  domains  within  a  single  application  is  not  a  requirement  for  our 
class  of  systems,  but  this  is  a  desired  capability. 

Rapid  prototyping  can  be  easily  accomplished  through  the  simulation  capability.  The 
Application  Specialist  can  quickly  compose  an  application  and  simulate  its  execution.  If 
the  behavior  meets  the  requirements,  then  the  Application  Speciadist  can  continue  to  refine 
the  application;  if  not,  then  the  Application  Specialist  can  modify  the  application  or  throw 
it  away  and  start  over. 

We  use  the  term  “simulating”  rather  than  “running”  because  no  code  has  been 
generated.  The  system  uses  the  current  application  specification  and  any  selected  reusable 
components  to  simulate  the  behavior  that  would  be  expected  if  code  had  been  generated 
cind  executed.  Through  simulation,  the  Application  Specialist  can  validate  the  application’s 
behavior  and  modify  the  specification  imtil  it  meets  the  desired  behavior. 

After  the  application  is  validated,  the  Application  Specialist  can  transform  it  into 
Em  executable  form  (i.e.,  synthesize  code)  for  a  particular  target  platform.  At  any  stage 
of  application  development,  the  Application  Specialist  can  save  the  current  application 
specification.  This  environment  also  supports  application  mmntenance  by  allowing  the 
Application  Specialise  to  load  wd  then  modify  the  application. 

3.2.2  Knowledge  Base.  Although  specific  knowledge  bases  vary,  every  DOACS 
knowledge  beise  contains  at  least  three  distinct  types  of  information:  applications,  reusable 
components,  and  domain  model  representations. 
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Applications  are  compositions  of  the  reusable  components,  along  with  composi¬ 
tion  information  (e.g.,  how  they  are  connected,  execution  order).  Therefore,  applications 
contain  either  links  to  the  reusable  components  they  employ  or  copies  of  each  reusable 
component.  If  links  are  maintained,  then  the  attribute  values  that  have  been  changed  by 
the  Application  Specialist  are  also  saved. 

Reusable  components  (we  will  often  refer  to  them  as  just  components)  are  the 
objects  that  are  connected  together  to  build  applications.  Reusable  components  are  ei¬ 
ther  primitives  or  reusable  applications.  Primitives  are  independent  objects  that  capture 
the  behavior  and  attributes  of  objects  and  clatsses  specified  during  domain  analysis  and 
identified  in  the  domain  model.  Reusable  applications  are  those  applications  (or  parts 
of  applications)  identified  for  potential  reuse  within  future  applications.  They  are  some¬ 
how  processed  to  make  them  available  to  the  Application  Specialist  for  composition  into 
applications  just  like  the  primitives. 

Domain  model  representations  are  formal  structures  that  organize  the  reusable 
components  and  other  domain-specific  information  (such  as  data  types,  semantic  rules,  and 
perhaps  even  specific  architecture  information)  within  an  application  domain.  The  types 
of  information  in  a  peirticular  representation  depend  primaiily  on  the  specific  application 
domain  and  on  the  chosen  approach  to  domain  analysis.  We  discuss  our  view  of  domain 
models  and  their  representations  in  more  detail  in  Section  3.3. 

3.2.3  Populate  Knowledge  Base.  The  Populate  Knowledge  Base  process  is 
the  focus  of  om  reseeurch  and  is  the  topic  of  the  rest  of  this  chapter.  Briefiy,  knowledge 
base  population  is  a  process  in  which  the  Domain  Engineer  captxires  domain  information 
as  high-level  abstreictions,  and  the  Software  Engineer  represents  these  abstreictions  in  a 
form  that  is  stored  directly  in  a  particular  system’s  knowledge  base. 

In  our  generd  process,  population  begins  by  selecting  em  object-oriented  Domain 
Analysis  appro2u:h.  The  Domain  Engineer  models  a  particular  application  domain  using 
the  domain  analysis  approach  chosen.  The  result  of  the  domain  analysis  is  a  domain  model 
and  individual  component  abstractions  (i.e.,  component  behavior  definitions). 
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The  Software  Engineer  uses  the  domain  model  and  the  individual  component  ab¬ 
stractions  to  create  the  formal  structure  of  that  domain  in  the  knowledge  base.  We  call 
this  construction  of  a  domain  model  representation  the  Domain  Implementation.  The 
domain  model  representation  is  a  particular  instantiation  of  a  domain  model  and  the  indi¬ 
vidual  component  abstractions  for  a  specific  DOACS  knowledge  base.  Once  instantiated, 
the  Software  Engineer  adds  the  domain  model  representation  to  the  knowledge  base.  The 
Application  Specialist  can  then  access  any  new  information  when  composing  applications 
in  that  domain. 

We  borrowed  the  term  reuse  infrastructure  from  Arango  (4)  and  Prieto-Diaz  (31) 
to  refer  to  a  domsdn  model  representation.  We  developed  our  process  to  keep  the  domain 
model  eis  independent  of  the  particular  DOACS  imd  its  knowledge  base  structure  as  pos¬ 
sible.  This  independence  delays  (for  as  long  as  possible)  the  addition  of  any  particular 
system  constraints  to  the  analysis  process.  The  view  of  a  domain  model  being  different 
from  its  reuse  infrastructure  is  important  to  our  development  of  a  general  knowledge  base 
population  process. 

S.3  Domain  Models  and  Reuse  Infrastructures 

The  terms  domain  model  and  reuse  infrastructure  ue  central  to  om:  research  and, 
in  our  opinion,  are  ill-defined  in  the  current  literature  where  they  take  on  many  different 
meanings.  In  this  section,  we  define  the  meanings  of  these  two  terms  with  respect  to  our 
research. 

Many  researchers  have  viewed  the  results  of  a  domain  analysis  as  a  set  of  reusable 
software  components  and  composition  niles  that  capture  and  implement  the  semantics  of 
applications  within  the  domain.  Given  this  interpretation,  however,  Domain  Engineers 
mxist  know  the  particular  knowledge  base  structure  before  completing  their  domain  analy¬ 
sis.  Domain  analysis  becomes  a  task  of  finding,  identifying,  organizing,  and  implementing 
reusable  components.  Domain  Engineers  become  the  people  responsible  for  populating  the 
knowledge  base  zmd  collecting  the  results  of  their  domain  analysis  within  the  knowledge 
base  structure  itself. 
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This  approach  can  lead  to  quick  and  efficient  domain  implementations,  but  can  also 
lead  to  several  problems  because  of  inherent  limitations  in  any  knowledge  base.  Because 
all  domain  information  cannot  be  stored  in  a  particular  knowledge  base,  it  is  difficult  to 
reuse  the  domain  analysis  results  to  populate  the  knowledge  base  of  another  DO  ACS. 
Also,  problems  can  occur  when  identifying  or  changing  the  design  of  the  domain  model  or 
making  other  changes  as  new  information  is  discovered  (e.g.,  better  domain  implementation 
methods),  because  some  domain  information  may  have  been  lost  through  design  decisions 
when  populating  the  knowledge  base.  In  addition,  if  the  Domain  Engineer  views  a  domain 
through  the  structure  of  a  particulu  knowledge  base,  it  will  influence  the  interpretation 
of  domain  knowledge  and  may  result  in  missed  or  incorrect  domain  encapsulation.  This 
problem  is  similar  to  the  difficulty  in  identifying  seemingly  simple  solutions  to  a  problem 
when  viewing  it  through  the  wrong  paradigm. 

For  these  reasons,  among  others,  we  make  a  distinction  between  the  results  of  the 

domain  analysis  (domain  model  and  component  abstractions)  and  the  implementation  of 

the  domain  (or  reuse  infrastructure)  in  the  knowledge  base.  Therefore,  although  many 

reseeurchers  have  assumed  the  domain  model  and  its  reuse  infrastructure  (domain  model 

representation)  are  one  and  the  same,  we  agree  with  Arango: 

Models  of  domains  and  reuse  infrastructure  should  be  treated  as  separate  en¬ 
tities,  conceptually  and  practically.  Models  of  domains  capture  the  results  of 
the  learning  process  in  domain  analysis  and  support  the  application  of  learning 
techniques.  Reuse  infrastructures  are  specifled  to  support  the  efficient  reuse  of 
the  information  from  the  model  in  particular  environments  (4:88). 

This  division  between  domain  analysis  and  domain  implementation  that  we  are 
proposing  is  similar  to  a  division  in  compilers.  Compiler  theory  makes  a  distinction  between 
the  intermediate  code  generated  by  the  front  end  (analogous  to  our  Domain  Analysis)  and 
the  machine  code  generated  by  the  back  end  (analogous  to  our  Domain  Implementation). 
The  front  end  of  the  compiler  includes  those  portions  of  the  compiler  “that  depend  pri¬ 
marily  on  the  source  language  and  are  largely  independent  of  the  target  machine  ...  [while] 
the  back  end  includes  those  portions  of  the  compiler  that  depend  on  the  target  machine, 
and  generally,  these  portions  do  not  depend  on  the  source  language,  just  the  intermediate 
language”  (1:20).  The  front  end  can  be  created  once  for  a  language,  and  then  different  back 
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ends  can  be  combined  with  it  to  create  compilers  for  different  machines.  In  our  generic 
methodology,  we  propose  that  domain  analysis  and  domain  implementation  are  analogous 
to  the  front  and  back  ends  of  a  compiler.  The  results  of  one  domain  analysis  can  be  used 
to  populate  different  DOACSs. 

S.S.l  Domain  Model.  The  software  engineering  community  has  many  different 
views  on  what  constitutes  a  domain  model.  In  G-DOACS,  a  domain  model  is  a  structure 
that  captures  an  application  domain’s  individual  components  (including  their  attributes 
and  operations),  relationships  between  components,  and  other  related  information  (such 
as  shared  data  types,  global  operations,  composition  niles,  and  architecture  information). 
Prieto-Diaz  suggested  that  the  the  purest  form  for  a  domain  model  would  be  a  domain 
language  (31:52)  that  captures  all  the  information  about  a  domain  listed  above.  The 
syntax  of  such  a  language  would  capture  the  types  of  components  (with  their  attributes) 
and  the  ways  they  can  be  combined,  while  the  semwtics  woiild  capture  the  the  behaviors 
of  component  combinations. 

For  our  process,  we  chose  not  to  include  the  individual  component  behaviors  (se¬ 
mantics)  as  part  of  the  domain  model.  We  separated  the  component  behaviors  from  the 
domain  model  becaiise  defining  behaviors  is  often  the  most  difficult  task  during  domain 
analysis.  Also,  users  can  compose  applications  with  a  well-defined  domain  model  imple¬ 
mentation  but  with  only  partially  defined  (and  implemented)  component  behaviors.  This 
allows  a  Domain  Engineer  to  quickly  capture  a  small  “core”  of  domain  knowledge  (the  do¬ 
main  model  plus  a  few  of  the  component  behaviors)  that,  once  implemented,  provides  the 
Application  Specialist  the  capability  to  compose  simple  applications  before  many  of  the 
component  behaviors  have  been  defined.  Under  our  definition,  the  domain  model  contains 
only  the  information  that  fully  describes  the  syntax  of  an  application  domain;  individual 
component  behaviors  are  defined  and  implemented  separately. 

In  this  chapter  and  those  that  follow,  we  describe  two  instances  of  the  domain  model. 
The  first  is  the  domain  model  created  during  the  domain  analysis  process  (as  described  in 
the  preceding  paragraph);  the  second  is  the  implementation  of  the  domain  model  in  the 
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knowledge  base.  The  instance  we  are  identifying  with  the  term  domain  model  should  be 
clear  from  the  context. 

3.3.2  Reuse  Infraatructurt.  As  stated  previously,  the  results  of  the  domain  analy¬ 
sis  should  be  independent  of  any  particular  DOACS.  So  ideally  the  domain  analysis  outputs 
a  domain  model  and  component  abstractions  without  constraints  to  their  usefulness  to  any 
particular  DOACS.  This  approach  follows  the  established  software  engineering  practice  of 
piishing  design  decisions  down  to  the  lowest  possible  level.  If  the  domain  analysis  is  done 
correctly,  the  domain  model  and  component  abstractions  can  be  evolved  over  time  without 
the  need  to  reanalyze  the  whole  domain.  The  domiun  analysis  results  can  also  be  used  to 
popiilate  the  knowledge  base  of  any  DOACS  (i.e.,  the  results  are  reusable^). 

Since  the  domsiin  analysis  results  are  derived  independent  of  the  knowledge  base 
structiire,  the  system  cannot  use  them  to  generate  applications.  Therefore,  the  Software 
Engineer  must  organize  and  implement  the  domiun  model  and  component  abstractions  into 
the  correct  knowledge  base  representation  for  some  particular  DOACS.  We  call  this  instan¬ 
tiation  of  the  domain  analysis  results  the  retise  infrastructure.  The  reuse  infrastructure 
implements  the  information  captured  in  the  domain  model  and  component  abstractions  in 
the  form  required  by  the  structme  of  a  particular  knowledge  base.  IVaditional  software 
engineering  methods  apply  to  the  development  of  any  reuse  infrastructure. 

Separating  the  reuse  infrastructure  from  the  domain  analysis  results  allows  us  to 
develop  our  knowledge  base  population  process  without  introducing  constraints  too  early 
in  the  process.  Before  presenting  our  process,  we  will  discuss  several  theories  that  were 
helpful  in  our  research. 

3.4  Domain  Analysis  Research 

In  Chapter  II,  we  summarized  the  ciurent  literature  in  the  field  of  domain  analysis 
and  discussed  the  relation  between  this  field  and  our  research  in  knowledge  base  population. 
This  section  summarizes  some  of  the  contributions  of  two  recognized  researchers  in  the 

^Methods  to  capture  domain  information  in  an  object-oriented  database  feeding  the  knowledge  bases  of 
several  DOACS  are  addressed  by  Cecil  and  FuUenkamp  (7). 
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field:  Prieto-Diaz  and  Arango.  Prieto-Diaz  (32)  proposed  a  functional  model  of  a  domain 
analysis  process  while  Arango  (4)  explored  the  domain  analysis  process  in  a  formal  software 
reuse  system.  Our  process  is  built  upon  many  of  their  contributions. 

3.4-1  Prieto-Dtaz's  Research.  According  to  Prieto-Diaz  (32),  domain  analysis 
captures  the  “essential  functionality”  of  components,  which  assists  the  application  devel¬ 
oper.  He  proposed  the  data  flow  diagram  in  Figme  3.2  with  three  activities  that  are 
involved  with  domain  analysis:  prepare  domain  information,  analyze  domain,  and  pro¬ 
duce  reusable  workproducts.  These  three  activities  comprise  the  task  of  knowledge  base 
population. 


EXISTING 

SYSTEMS 


Figure  3.2  Producing  Reusable  Workproducts  (32:67). 

The  prepare  domain  information  activity  produces  the  requirements  of  the  domain 
Euialysis.  This  activity  includes  bounding  the  application  domain,  identifying  the  sources 
for  domain  knowledge,  selecting  a  specific  domain  analysis  approach,  and  defining  the 
expected  results. 

The  analyze  dommn  ^«:tivity  uses  these  requirements  to  produce  collections  of  do¬ 
main  abstractions  including  the  domain  model,  domain  frames,  a  domain  taxonomy,  and 
a  domain  language.  This  activity  is  the  domain  analysis  theory  proposed  by  Prieto-Diaz 
-  we  previously  presented  the  details  of  the  analyze  domain  activity  with  the  data  flow 
diagrjun  in  Figure  2.1.  The  domain  abstractions  capture  the  behavior  of  objects  within 
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the  domain,  identify  their  relationships,  and  model  the  structure  of  these  relationships. 
Prieto-Disus  suggested  that  the  ideal  resiilt  of  domain  analysis  is  the  domain  language. 

The  produce  reusable  workproducts  activity  takes  the  domain  abstractions  and  pro¬ 
duces  a  set  of  reusable  components.  The  components  implement  the  objects  and  relation¬ 
ships  identified  in  the  domain  model  and  used  in  the  domain  language. 

Prieto-Diaz  proposed  a  functional  model  that  successfully  identifies  the  relationship 
between  domain  Einalysis  and  the  production  of  a  reusable  infrastructure.  It  also  suc¬ 
cessfully  defines  several  outputs  involved  in  the  process;  however,  it  does  not  sufficiently 
describe  the  requirements  of  each  activity.  For  instance,  there  is  nothing  that  constradns 
the  structme  of  the  reusable  components.  Systematic  reuse  cannot  be  realized  without 
such  constraints.  His  model  does  not  explicitly  capture  the  importance  of  feedback  and 
iteration  in  the  domain  analysis  process,  nor  does  it  identify  the  role  of  the  knowledge  base 
in  separating  the  reuse  infrastructure  from  the  domain  model. 

3.4-2  Arango  'a  Research.  Arango  (4)  outlined  a  “domain  engineering  framework” 
based  on  the  concepts  of  software  reuse.  His  framework  serves  as  a  structure  for  S3mthe- 
sizing  a  tsulored  domain  analysis  process.  Arango  suggested  his  framework  has  general 
application  because  reusers  are  modeled  as  learning  systems. 

Figure  3.3  describes  the  learning  component  using  boxes  from  the  Structured  Analysis 
and  Design  Technique.  The  component  consists  of  three  activities  and  is  defined  by  a  set 
of  state  variables  (4:84): 

•  Exp:  expertise  in  the  domain 

•  ReuseLog:  feedback  from  the  reuse  task 

•  Rl:  reuse  infrastructure 

•  Tl:  technologies  to  support  the  representation  and  evolution  of  the  domain  model 

•  MoD:  domain  model 

•  Lc:  method  to  increase  coverage 

•  Le:  method  to  improve  efficiency 
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Figure  3.3  Develop  Reuse  Infrastructure  (4:85). 


•  MoT:  model  of  the  reuse  task 

The  develop  MoD  activity  represents  the  actual  domain  analysis  and  results  in  a 
domain  model.  Arango  made  a  clear  distinction  between  the  domain  model  and  the  reuse 
infrastructure.  He  stated  that  the  distinction  is  analogous  to  the  distinction  between 
“representations  for  systems  specifications  and  progr2unming  languages  for  systems  imple¬ 
mentations”  (4:82).  This  distinction  allows  the  domain  model  to  be  independent  from  the 
MoT. 

The  other  two  activities  use  the  current  state  of  the  domain  model  to  organize  and 
implement  a  reuse  infrastructiure.  The  particular  org2uiization  and  implementation  de¬ 
pend  heavily  upon  the  particular  MoT.  Traditional  software  development  procedures  are 
applicable  during  these  two  activities. 

Arango’s  learning  component  is  very  similar  to  the  functional  model  proposed  by 
Prieto-Diaz.  It  separates  the  creation  of  a  domsun  model  from  the  development  of  the  reuse 
infrastructure.  Aremgo  successfully  identified  the  various  traits  involved  in  the  development 


3-12 


of  a  reuse  infrastructure.  He  also  explicitly  indicated  the  roles  of  feedback  and  iteration. 
However,  his  state  variables  were  too  ambiguous.  He  did  not  suflBciently  describe  the  model 
of  the  reuse  task  or  the  role  of  the  knowledge  base,  which  are  essential  in  developing  the 
reuse  infrastructure.  There  was  edso  no  clear  distinction  between  the  results  of  infrastruc¬ 
ture  specification  euid  those  of  infrastructure  implementation.  Prieto-Diaz  had  combined 
these  two  activities  into  his  produce  reusable  workproducts,  but  Aremgo  seemed  to  think 
there  should  be  some  distinction.  Our  research  combines  these  two  processes  into  a  single 
knowledge  beise  population  process.  We  attempt  to  clarify  all  trmts  involved  in  knowledge 
base  population  without  adding  additional  constrciints  to  the  process. 

3.5  Knowledge  Base  Population  Process 

We  propose  a  five-step  process  to  knowledge  base  population  that  explicitly  identi¬ 
fies  the  roles  of  the  Domain  juid  Software  Engineers,  incorporates  feedback,  and  iteratively 
captures  a  domain  (in  stages).  Each  step  has  defined  inputs,  outputs,  methods,  and  con¬ 
straints.  Our  process  is  shown  in  Figure  3.4,  using  boxes  from  the  Structured  Analysis  and 
Design  Technique.  The  methods  (bottom  arrows)  driving  each  activity  or  step  must  be 
selected  prior  to  performing  the  activity.  The  constraints  (top  arrows)  show  the  require¬ 
ments  that  drive  each  activity.  The  inputs  and  outputs  (left  and  right  arrows,  respectively) 
show  the  domain  information  as  it  is  captured  and  passed  from  e«:tivity  to  activity. 

Activities  one  and  two  compose  our  domain  analysis  process  and  result  in  a  domain 
model  and  component  abstractions.  As  discussed  in  previous  sections,  this  domain  smalysis 
is  independent  of  the  particular  DOACS.  Activities  three  and  four  comprise  our  domain 
implementation  process  that  results  in  a  reuse  infreistructure  and,  as  can  be  seen  from 
the  constraints,  that  is  very  dependent  on  the  particular  DOACS.  This  division  between 
domain  analysis  and  domain  implementation  is  such  that  one  domain  anaJysis  can  feed 
multiple  domain  implementations  for  different  DOACS.  Activity  five  provides  an  evaluation 
and  feedbaick  mechanism  to  iteratively  improve  the  domain  model,  component  abstractions, 
and  the  reuse  infreistructure.  The  remainder  of  this  section  defines  each  activity  amd  adl 
its  associated  traits. 
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Figure  3.4  Knowledge  Base  Population 


3.5.1  Create/Evolve  Domain  Model  The  first  step  in  populating  the  knowledge 
base  of  a  DOACS  with  a  particular  domain  is  generating  a  domain  model.  A  domain  model 
is  created  during  the  initial  domain  modeling®  activity  and  periodically  updated  through 
subsequent  iterations.  Before  performing  the  initial  iteration  of  this  process,  the  methods 
and  constrmnts  must  be  defined,  including  the  specific  domain  modehng  approach  2uid  the 
formal  modeling  requirements. 

The  Domain  Engineer  should  select  the  domain  modeling  approach  based  on  the 
strengths  cind  weedcnesses  of  the  approzich  emd  on  the  characteristics  of  the  particular  do- 
mcun  to  be  analyzed.  We  recognize  that  factors  such  as  the  Domeiin  Engineer’s  familiarity 
with  certain  modehng  approaches,  m^magement’s  overall  goals,  and  the  availabihty  of  re¬ 
sources  will  also  play  an  import2mt  role  in  choosing  a  specific  approach.  Any  well-defined 
object-oriented  modehng  approach  should  be  sufficient  since  our  methodology  requires 

^In  keeping  with  our  definitions  presented  in  Chapter  II,  we  considered  domain  modeling  to  be  a  type 
of  domain  analysis  that  results  in  a  domain  model  with  some  formalized  structure. 
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consistency  and  completeness*  of  the  resulting  domain  model,  but  puts  no  restrictions  on 
the  form  of  this  model  (other  than  object-oriented).  The  Domain  Engineer  is  the  one  who 
will  have  to  use  the  approach  to  create  and  update  the  domain  model.  Therefore,  the 
approach  must  be  thoroughly  imderstood.  Also,  the  approach  should  take  advantage  of 
any  available  automated  domain  analysis/modeling  tools  to  aid  in  capturing  the  domain. 
Such  tools  could  improve  performance  smd  could  aid  in  maintaining  the  domain  model’s 
consistency  Jind  completeness  (information  on  one  such  tool  czm  be  foimd  in  Crowley’s 
research  (10)).  We  expect  that  these  tools  will  be  tied  together  after  they  (and  DOACS) 
become  more  established  (effectively  automating  much  of  the  role  of  the  Softwzure  Engi¬ 
neer). 

The  modeling  requirements  come  from  both  the  domain  modeling  approach  cho¬ 
sen  as  well  as  the  feict  that  domain  analysis  must  be  accomplished  using  object-oriented 
techniques.  The  minimum  modeling  requirement  consists  of  a  formal  structure  that  en¬ 
capsulates  all  the  information  represented  in  the  domain  model.  The  structure  is  similar 
to  a  meta-model  structure  (proposed  by  Iscoe  (14))  and  should  be  in  some  object-oriented 
form. 

Once  the  domain  modeling  approach  and  modeling  requirements  have  been  defined, 
the  Domain  Engineer  can  begin  creating  the  domain  model.  The  domain  model  is  trans¬ 
formed  from  a  simple  hierarchy  of  abstraction  identifiers  to  a  formal  structure  of  captured 
domain  sememtics  (which  ideally  leads  to  a  domain-specific  language).  As  the  domain 
model  evolves,  the  Software  Engineer  can  begin  applying  the  constrmnts  of  a  knowledge 
base  for  a  particular  DOACS  to  construct  a  reuse  infrastructure  (i.e.,  instemtiate  the  do¬ 
main  model).  However,  before  discussing  the  domain  implementation,  we  must  address 
the  task  of  defining  individual  component  abstractions. 

3.5.2  Abstract  Component  Behavior.  After  a  structure  has  been  created  contain¬ 
ing  components  in  the  domain,  the  behavior  of  the  individual  components  must  be  defined. 
McCain  refers  to  this  process  bs  “component  domain  analysis”  (25:73).  The  abstraction 

*By  completeness,  we  do  not  mean  that  the  domain  model  has  to  capture  the  whole  domain,  but  rather 
that  the  parts  of  the  domain  that  it  does  capture  are  completely  captured  within  the  scope  of  the  domain 
analysis  appro^lch. 
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technique  chosen  by  the  Domain  Engineer  must  be  consistent  with  the  modeling  approach 
used  in  the  Create/Evolve  Domain  Model  activity  (ideally,  they  both  should  be  part  of 
an  integrated  dommn  analysis  approach).  The  results  of  the  abstraction  technique  should 
be  in  a  form  that  the  Software  Engineer  understands  and  can  implement.  For  example,  it 
is  possible  to  create  Z  schemas  that  cannot  be  implemented  on  a  computer  system.  The 
distinct  features  of  the  domain  under  analysis  should  also  play  a  role  in  which  abstraction 
technique  the  Domain  Engineer  chooses.  However,  although  different  abstraction  tech¬ 
niques  may  be  used  for  different  domains,  using  the  same  technique  within  a  domain  is 
required. 

One  of  the  most  important  aspects  of  the  component  abstraction  is  the  interface 
specification.  Although  object  interfaces  could  have  been  partially  defined  during  the 
previous  activity  (if  not  completely  defined,  depending  on  the  modeling  approach  chosen), 
each  component  abstraction  must  have  interfaces  that  support  consistent  relationships 
between  other  component  abstractions.  The  Domain  Engineer  must  keep  in  mind  that  this 
whole  process  is  based  on  an  object-oriented  methodology  and  that  the  final  result  will 
be  objects  that  can  be  connected  together.  Incorrect  or  inconsistent  component  interfaces 
will  cause  severe  problems  when  the  Software  Engineer  tries  to  implement  the  abstractions 
and  also  when  the  Application  Specialist  attempts  to  compose  applications. 

Another  expect  of  ezwii  component  abstraction  is  the  effect  of  certain  component  at¬ 
tribute  values.  Attributes  contain  data  that  represents  characteristics  of  an  object  (20:20). 
These  charsu:teristics  may  have  a  large  impact  on  the  behavior  of  a  particular  component. 
The  Domain  Engineer  must  identify  these  impacts  during  this  activity.  For  example,  a 
component  that  converts  a  real  number  to  am  integer  may  have  am  attribute  that  spec¬ 
ifies  whether  that  component  will  do  the  conversion  by  roimding  to  the  neaurest  integer, 
truncating,  or  roimding  up  to  the  next  integer.  One  useful  feature  of  a  DOACS  is  the 
ability  for  the  Application  Specialist  to  diamge  these  component  attributes  and  “tadlor” 
the  component  for  a  specific  application.  However,  components  cam  have  attributes  that 
should  not  be  chamged  by  the  Application  Specialist  (for  example,  attributes  that  reflect 
the  intemad  state  of  the  component).  These  intemad  attributes  should  also  be  identified 
during  this  aictivity. 
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It  is  expected  that  the  Domain  Engineer  may  identify  better  ways  to  model  the  do- 
mun  at  this  stage  of  the  process.  For  example,  at  this  point,  the  Domain  Engineer  may 
choose  to  combine  objects  or  classes  (generalization),  or  split  an  object  or  class  (special¬ 
ization).  These  improvements  zure  acceptable  (smd  even  desirable).  As  stated  before,  our 
process  is  iterative.  Component  abstractions  are  evaluated  (by  the  Evaluate  Domain  De¬ 
velopment  activity),  and  the  Domain  Engineer  is  notified  of  any  problems.  Our  study  of 
domain  anzfiysis  revealed  that  the  best  domain  model  is  the  one  that  has  evolved  over  time 
(i.e.,  it  is  difficult  to  come  up  with  the  best  model  on  the  first  iteration). 

We  recognize  that  the  Domain  and  Software  Engineers  may  choose  to  merge  this 
activity  wit' .  the  Implement  Reusable  Components  activity  by  using  a  DOACS-specific 
method  to  define  and  implement  individual  component  behaviors.  This  could  save  time 
and  effort  during  the  domain  analysis,  but  it  has  its  drawbacks.  When  system  require¬ 
ments  and  implementation  requirements  constrain  the  definition  of  individual  component 
behaviors,  biases  could  easily  enter  into  the  component  definitions  (e.g.,  implementation 
details  often  “muddy  the  water”  of  a  “pure”  domain  analysis).  Any  bias  introduced  at 
this  early  stage  may  cause  difficulties  as  the  domain  implementation  evolves.  Also,  ab¬ 
stracting  component  behaviors  in  this  way  may  make  it  difficult  (or  impossible)  to  reuse 
the  abstracted  components  to  populate  another  DOACS. 

3.5.3  Design  Reuse  Infrastructure.  The  domain  model  is  a  structure  (much 
like  the  syntax  and  semantics  of  a  grammar)  that  captures  the  individual  components, 
relationships  between  components,  and  other  related  information  in  an  application  dommn. 
The  Softweire  Engineer  must  now  organize  the  information  captured  in  the  domain  model 
into  a  form  that  can  be  stored  in  the  knowledge  beise  of  the  particular  DOACS.  The 
orgcinized  abstractions  become  the  domain’s  reuse  infrastructure  design.  The  infirastructure 
design  is  similar  to  Armgo’s  reuse  infrastructiure  specification  that  acts  as  “an  architecture 
for  reusable  information”  (4:82).  In  designing  the  reuse  infrastructure,  current  software 
engineering  methods  should  be  used;  however,  these  methods  must  fit  into  the  object- 
oriented  paradigm.  Also,  the  Softwjure  Engineer  must  understmd  and  follow  any  other 
design  requirements  (e.g.,  organization-specific  design  standards). 
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The  implementation  of  this  process  is  very  system-specific;  however,  the  results  of 
this  activity  will  usually  form,  as  a  minimum,  an  abstract  s}mtax  tree  with  each  node  rep¬ 
resenting  some  abstraction  and  each  leaf  representing  a  component  implementation.  More 
sophisticated  DOACS  will  reqviire  more  sophisticated  results  like  implemented  domain- 
specific  languages,  domain  semantics  (e.g.,  a  domain  rule  that  component  A  must  follow 
component  B),  domain-specific  software  architectures,  and  methods  for  defining  how  the 
components  are  presented  to  the  Application  Specialist  during  the  composition  process. 

3.5.4  Implement  Reusable  Components.  Now  that  the  reuse  infretstructiu'e  has 
been  designed  and  the  component  behaviors  have  been  defined,  the  individual  components 
must  be  implemented  (transformed  into  the  required  “executable”  form).  Component 
implementation  is  a  translation  of  each  component  &om  its  abstract  definition  into  a  form 
representable  in  the  knowledge  base  and  executable  by  the  DOACS. 

The  Software  Engineer  implements  each  abstraction  organized  in  the  domain  infras¬ 
tructure  design.  The  implemented  abstractions  become  part  of  the  reuse  infrastructirre 
implementation  and,  when  all  of  them  are  done,  domain  implementation  is  complete.  Be¬ 
fore  implementing  the  components,  the  specific  software  development  tools  and  the  imple¬ 
mentation  requirements  must  be  identified. 

The  selection  of  software  development  tools  will  depend  on  the  softwsu'e  implemen¬ 
tation  languages  accepted  by  the  DOACS.  The  Softw^u:e  Engineer  should  use  whatever 
tools  are  available  to  implement  the  components.  Commercial  compilers  and  software  de¬ 
velopment  environments  cem  provide  the  necessary  utilities  to  perform  reuse  infrastructure 
implementation. 

The  implementation  requirements  constraint  indicates  the  constraints  imposed  by 
the  DOACS,  most  of  which  result  from  the  requirements  of  its  knowledge  base.  These  con¬ 
straints  must  include  a  formal  description  of  the  softwzu'e  architectures  supported  by  the 
DOACS  and  the  specific  procedmres  for  representing  component  implementations  within 
the  knowledge  beise.  The  implementation  requirements  should  also  identify  different  meth¬ 
ods  to  model  the  component  abstrzK;tions.  For  example,  a  st£u:k  data  type  can  be  imple¬ 
mented  as  an  array  or  list  with  veurious  advantages  to  each  of  these  implementations.  Part 
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of  the  implementation  reqtiirements  should  detiul  the  procedures  for  selecting  the  desired 
implementation  method  for  different  abstractions. 

A  priority  list  of  the  order  to  implement  the  components  may  also  be  included  in  the 
implementation  requirements.  The  Application  Specialists  may  require  some  components 
inunediately,  while  other  components  may  not  be  needed  until  well  in  the  future.  Using 
priorities,  the  Software  Engineer  could  implement  components  in  order  of  their  importance 
to  the  Application  Specialist.  This  allows  the  DOACS  to  support  application  composition 
before  complete  domain  implementation  is  finished. 

3.5.5  Evaluate  Domain  Development.  In  this  activity,  the  Software  and  Domain 
Engineers  evaluate  the  outputs  of  the  previous  activities.  This  activity  covers  a  broader 
scope  than  the  others  because,  while  the  others  are  focused  on  one  area  of  domain  analy¬ 
sis/implementation,  this  activity  has  relevance  to  the  entire  knowledge  base  process  from 
start  to  finish. 

The  results  of  each  of  the  other  four  aM:tivities  should  be  evaluated  as  they  are  gener¬ 
ated,  both  individually  and  along  with  restdts  from  previously  completed  activities.  Also, 
when  all  the  results  are  completed,  they  should  again  be  evaluated  to  ensiue  consistency 
and  completeness.  This  activity  should  trigger  one  or  more  of  the  previous  2u;tivities  when 
errors  or  better  ways  to  model/implement  the  domain  eire  discovered.  Each  2ictivity  could 
include  their  own  evaluations  as  part  of  their  normed  execution,  but  we  have  made  the 
evaluation  a  sepairate  activity  to  provide  a  way  to  evaluate  the  results  of  edl  the  activities 
in  reference  to  one  another. 

Although  we  have  placed  this  activity  at  the  end  of  our  process,  it  is  involved  at 
each  step  of  the  knowledge  base  population  process.  As  the  domain  model  and  knowledge 
bz«e  evolve,  this  eictivity  becomes  more  important  in  maintaining  the  integrity  of  the 
applications  they  generate. 

An  input  to  this  activity  that  is  not  specifically  shown  on  Figure  3.4,  but  is  worthy 
of  mention,  is  from  the  Application  Specialist.  As  the  Application  Specialist  composes 
applications,  several  problems  may  be  identified  (such  as  missing  components,  errors  in 
components,  or  problems  with  component  interfaces).  The  Domain  Engineer  then  evaluates 
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the  problems  and  makes  any  necessary  changes  to  the  domain  model  or  rexise  infrastructure. 
Another  input  from  the  Application  Specialist  is  the  identification  of  applications  that 
should  be  incorporated  into  the  knowledge  base  as  primitive  components.  These  reusable 
applications  eure  discussed  in  the  next  section. 

3.5.6  Reusable  Applications.  Along  with  the  components  identified  during  the 
domain  zmalysis,  the  Application  Specialist  may  want  to  use  am  existing  application  (or 
part  of  one)  as  a  component  in  a  new  application.  We  call  this  reused  application  a 
reusable  application  (although  all  applications  are  reused  in  the  sense  that  they  can 
be  reloaded  and  modified).  When  the  Application  Specialist  is  choosing  components  to 
use  in  composing  an  application,  these  reusable  applications  should  be  included  in  the  list 
of  choices.  It  is  possible  that  a  DOACS  could  implement  reusable  applications  without 
any  special  processing;  however,  in  general,  we  expect  that  these  applications  will  need  to 
be  identified  for  reuse  and  somehow  “processed”  by  the  Domain  and  Software  Engineers. 
This  processing  is  completely  dependent  on  the  specific  DOACS,  and  there  could  even  be 
different  methods  for  accomplishing  this  within  the  same  DOACS. 

The  creation  of  a  reusable  application  may  be  simple  or  complex,  depending  on  the 
specific  situation  and  tlis  capabilities  of  the  system.  Primitive  application  creation  could 
consist  of  stripping  off  desired  data  “sources”  and  “sinks”  (components  that  generate  or 
consume  data  that  we  now  want  to  leave  off  the  application)  and  identifying  the  interface 
to  the  reusable  application  that  remains  after  these  components  are  removed.  If  the  spe¬ 
cific  DOACS  does  not  have  the  capability  of  storing  and  using  a  reusable  application  like 
this,  then  the  Software  Engineer  may  have  to  somehow  combine  all  the  behaviors  of  the 
components  of  this  application  into  this  new  component  in  the  same  manner  as  those  iden¬ 
tified  in  the  domain  analysis.  Also,  depending  on  the  specific  DOACS,  it  may  be  required 
that  this  new  primitive  application  be  added  into  the  reuse  infrastructure  design. 

Along  with  making  the  reusable  application  available  as  a  new  component  to  the 
Application  Specialist,  the  Domain  Engineer  should  consider  adding  it  to  the  domain 
model  (in  the  Create/Evolve  Domain  Model  activity).  If  the  rextsable  application  is  added, 
then  its  behavior  shovild  be  captured  in  the  Abstract  Component  Behavior  activity  and 
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consideration  given  to  implem«ating  it  as  a  single  component  (rather  than  a  collection  of 
components). 

3.6  General  Process  Support  and  Constraints 

There  are  many  reasons  for  having  a  general  knowledge  base  popxilatiou  process.  One 
reason  is  to  provide  a  framework  to  use  when  developing  tools  and  utilities  that  apply  to 
populating  many  knowledge  bases.  Is  there  justification  for  developing  a  general  process? 
How  “general”  is  this  process?  This  section  is  our  attempt  to  support  our  development  of 
a  “general”  knowledge  base  population  process. 

We  have  illustrated  a  possible  knowledge  base  population  process.  We  attempted 
to  clarify  the  process  by  identifying  the  methods  and  constraints  for  each  activity;  they 
change  depending  on  the  specific  application  domain  and  the  specific  DOACS  used  to 
develop  applications.  This  versatility,  tying  each  of  these  traits  to  the  characteristics  of  the 
domain  or  system,  adds  justification  to  the  general  applicability  of  the  process.  Although 
the  domain  model  resiilting  from  the  domain,  analysis  is  independent  of  the  knowledge  base 
constraints,  the  model’s  structme  and  the  domain  analysis  method  used  to  create  it  can 
differ  for  each  domain.  This  characteristic  is  captured  in  the  first  stage  of  our  process.  The 
same  idea  applies  to  bxiilding  the  rexise  infrastructure.  The  infrastructure  can  be  different 
for  each  DOACS.  We  do  not  suggest  that  this  process  will  support  every  application  domain 
or  apply  to  all  DOACSs  (it  has  not  even  been  shown  that  every  domain  can  be  modeled 
using  current  modeling  techniques).  However,  we  do  suggest  that  this  process  will  support 
many  application  domains  and  many  systems. 

There  are  some  characteristics  that  must  exist  in  the  domain  and  the  system.  The 
system’s  knowledge  base  must  have  the  capability  to  represent  an  organized  collection  of 
reusable  software  components  and  the  rules  for  their  composition.  We  described  this  firame- 
work  in  Section  3.2.  The  domain  miist  be  somewhat  established  (i.e.,  some  structure  must 
exist  for  building  applications  in  the  domain,  either  informal  or  formal).  This  implies  that 
the  domain  is  mature  enough  to  have  existing  applications  that  could  provide  important 
information  during  a  domain  analysis. 
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We  have  developed  our  process  with  the  goal  of  future  automation.  Constraints 
placed  on  each  activity  (such  as  knowing  the  particular  software  architecture)  have  been  in¬ 
cluded  only  where  necessary.  However,  software  engineers  may  be  concerned  about  changes 
made  to  these  constraints  while  a  domain  model  and  knowledge  base  are  evolving.  For 
example,  suppose  we  modify  our  knowledge  base  structure  after  already  implementing  sev¬ 
eral  domains.  What  impact  does  this  have  on  the  knowledge  base  population  process? 
Will  we  have  to  respecify  and  re-implement  the  domain  model?  Are  we  forced  to  stick  to 
the  original  constraints?  Although  a  more  general  knowledge  base  population  process  may 
exist,  we  feel  that  our  process  can  handle  these  problems  if  the  proper  attention  is  given 
to  the  definition  of  each  constraint. 

3. 7  Summary 

A  formal  process  for  populating  a  knowledge  base  residts  when  we  apply  the  outline 
described  in  this  chapter  to  a  candidate  DOACS.  The  process  that  we  have  developed 
incrementally  evolves  the  domain  -  both  the  domain  model  and  the  reuse  infrastructure 
in  the  knowledge  base.  The  process  explicitly  captures  the  role  of  feedback  through  the 
evaluation  of  e2K;h  SK;tivity.  When  the  process  is  first  started  for  some  application  domain, 
most  of  the  effort  will  involve  the  Create/Evolve  Domain  Model  and  Abstract  Component 
Behavior  activities  (activities  one  and  two  of  Figure  3.4).  As  the  process  continues,  effort 
will  increase  in  the  Design  Reuse  Infrastructure  and  Implement  Reusable  Components 
zu;tivities  (activities  three  and  four  of  Figure  3.4).  The  attention  given  to  the  EvzJuating 
Domain  Development  activity  will  depend  on  the  particular  requirements  for  testing  (which 
usually  relates  the  size  and  complexity  of  the  domain). 

Although  we  have  developed  a  general  process,  software  engineers  need  to  conduct 
more  application-oriented  research  into  knowledge  base  population  to  gain  more  experience 
and  develop  tools  to  assist  in  evolving  domain  models  and  structuring  knowledge  bases. 
The  DOACS  concept  heis  not  yet  been  proven  in  the  software  engineering  community.  Our 
research  efforts  and  the  efforts  of  other  researchers  will  help  to  improve  these  software 
development  technologies. 
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IV.  Instantiation  of  tiie  Generic  Knowledge  Base  Population  Methodology  for 

Architect 

4.1  Introduction 

In  the  previoiis  chapter,  we  presented  a  generic  knowledge  base  population  process 
(Figure  3.4)  that  we  maintain  could  be  tulored  to  any  DOACS.  In  this  dii^ter,  we  in¬ 
stantiate  this  process  for  a  specific  DOACS:  Architect^  However,  before  presenting  our 
instantiation  of  the  generic  population  process,  we  must  first  describe  Architect. 

4.2  Architect 

Figme  4.1  (reprinted  from  Chapter  I)  shows  a  general  overview  of  the  current  version 
of  Architect  The  rounded  boxes  are  tasks  accomplished  by  the  Application  Specialist, 
Domain  Engineer,  and  Software  Engineer;  the  square  boxes  are  components  of  Architect. 

Architect  runs  within  the  Software  Refinery®*"  development  enviromnent  created  by 
Reasoning  Systems,  centered  around  a  Lisp-based  specification  language  called  Refine. 
The  Refine  language  “provides  an  integrated  treatment  of  set  theory,  logic,  transfor¬ 
mation  rules,  pattern  matching,  wd  procedure”  (34).  Programs  in  REFINE  consist  of 
executable  rules  and  functions  that  query  and  modify  a  powerful  object  base;  in  addition, 
there  are  many  built-in  functions  to  aid  in  manipulating  this  object  base.  The  user  de¬ 
fines  these  rules  and  functions  at  the  specification  level,  so  REFINE  supports  programming 
with  “executable  specifications”.  Also  included  in  Refine  is  a  syntax  definition  system, 
called  Dialect,  which  2dlows  users  to  easily  design  and  implement  new  languages,  through 
gramm£ur  definitions.  These  grammars  can  be  used  to  populate  the  Refine  object  base  by 
pausing  in  text  files,  an  ideal  way  to  implement  domain-specific  languages. 

Architect  fits  well  into  the  DOACS  concept  presented  in  Chapter  HI.  It  is  a  domain- 
oriented  application  composer  that  has  a  knowledge  base,  called  the  Technology  Base,  to 
encapsulate  domain  knowledge.  Through  the  Architect  Visual  System  Interface  (AVSI), 
the  Application  Specialist  can  view  domain  documentation,  compose  or  load  an  application, 

*In  Chapter  IV  of  (35),  Capt  Sandy  instantiates  this  same  process  for  a  DOACS  called  Automatic 
Programming  Technologies  for  Avionics  Software  (APTAS). 

^A  summary  of  other  research  accomplished  concurrently  with  this  effort  is  in  Chapter  I. 
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check  the  semantics  of  the  application,  execute  the  application,  and  save  the  application. 
An  application  is  composed  of  subsystems,  and  subsystems  are  composed  of  primitives 
and/or  other  subsystems.  The  Working  Technology  Base  is  contained  in  the  REFINE 
object  base  (non-persistent  between  Refine  environment  sessions);  the  Saved  Technology 
Base  currently  consists  of  a  directory  structure  containing  text  files’.  Architect  does  not 
yet  have  a  sophisticated  code  generation  capability  (applications  can  only  be  "run”  within 
the  scope  of  Architect);  however,  it  is  expected  that  this  capability  will  be  added  in  the 
future. 

Currently,  Architect  has  only  one  architecture  available,  which  is  based  on  the  OCU 
model.  This  model  is  summarized  in  the  following  section,  followed  by  a  section  describing 
the  Architect  implementation  of  this  model.  FinztUy,  a  description  of  how  to  create  an 
application  is  given. 
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Information  on  implementing  the  Saved  Technology  Base  in  a  database  is  contained  in  (7). 
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4-8.1  The  Object- Connection- Update  (OCU)  Model.  The  OCU  model  (20)  was 
developed  by  the  Software  Engineering  Institute  (SEI)  as  a  part  of  their  Software  Architec¬ 
tures  Engineering  Project.  In  the  OCU  model,  applications  consist  of  a  set  of  subsystems 
(see  Figure  4.2)  that  contain: 

•  A  Controller:  manages  the  objects  in  the  subsystem.  A  subsystem’s  controller  can  be 
accessed  through  the  following  procedures:  Update,  Stabilize,  Initialize,  Configure, 
Destroy. 

•  An  Import  Area:  the  collection  of  the  data  needed  by  the  objects  in  the  subsystem. 
It  consists  of  a  collection  of  the  inputjdata  of  all  the  objects  and  imports  of  all  the 
subsystems  that  are  contained  in  this  subsystem. 

•  An  Export  Area:  the  collection  of  the  data  produced  by  the  objects  in  the  subsystem. 
It  consists  of  a  collection  of  the  outputjdata  of  all  the  objects  and  exports  of  all  the 
subsystems  that  are  contained  in  this  subsystem. 

•  Objects  and  other  subsystems:  subsystems  can  be  nested  to  any  depth. 


“An  object  models  the  behavior  of  a  real-world  or  virtued  component  and  maintains 
state.  All  algorithms  that  are  necessary  to  model  the  behavior  of  the  component  are 
localized  in  an  object”  (20:19).  Objects  have: 

•  An  Interface;  consists  of  five  procedures; 
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-  Update:  calcxilates  the  new  object  state  data  based  on  the  current  state  and 
input  values. 

—  Create:  creates  a  new  instance  of  an  object. 

-  SetFunction:  switches  or  redefines  (by  coefl&cient  modifications)  the  update  pro¬ 
cedure. 

-  SetState:  modifies  the  object’s  state  data  directly. 

—  Destroy:  deallocates  the  object. 

•  Input-Data:  data  provided  by  other  objects  used  to  calculate  the  new  state  data. 

•  Output-Data:  data  resulting  from  an  object’s  state  calculations  that  is  externally 
visible. 

•  Attributes:  data  that  represent  characteristics  of  an  object. 

•  Current-State:  data  representing  the  current  condition  of  the  object. 

•  Coefficients:  data  used  in  the  sdgorithms  for  calculating  the  object’s  state  data. 

•  Constants:  data  that  represent  unalterable  object  attributes. 

It  is  important  to  note  that  while  the  SEI  developed  the  OCU  model,  to  our  knowl¬ 
edge  they  have  not  developed  any  automated  tool  support  systems  for  this  model.  Because 
of  this,  there  are  some  areas  of  the  OCU  model  that  need  more  detail  in  order  to  automate 
this  model.  For  exsunple,  exactly  what  form  rm  object’s  State.Data  takes  is  not  defined. 
Therefore,  during  AFIT’s  automation  of  the  OCU  model,  these  areas  had  to  be  defined 
to  a  greater  level  of  detail:  these  areas  have  caused  some  problems  in  the  Architect  OCU 
implementation.  Some  of  these  problems  eu:e  described  below  and  in  Chapter  V  because 
they  zdFect  the  implementation  of  a  domain  in  Architect. 

4.2.2  OCU  Implementation  in  Architect.  Because  there  are  some  areas  of  the 
OCU  model  that  are  not  completely  defined  to  a  sufficient  level  of  detail  to  be  automated, 
and  because  the  integration  of  the  OCU  model  in  any  DOACS  requires  that  implementation 
decisions  be  made,  the  OCU  model  implemented  in  Architect  differs  somewhat  from  the 
OCU  model  described  above.  In  this  section  we  identify  the  important  differences. 
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A  graphical  representation  of  the  structure  of  applications  is  shown  in  Figure  4.3.  In 
the  notation  used  in  this  figure*,  the  boxes  represent  object  classes  (there  may  be  many 
objects  of  these  types)  and  the  lines  represent  associations  between  objects  of  the  connected 
classes.  Black  circles  on  the  associations  show  that  there  cam  be  one  or  more  of  that  type 
of  object  on  that  end  of  an  instance  of  that  association.  An  object  class  has  three  parts: 
nzune,  attributes,  eind  operations,  which  are  divided  by  lines. 


Figure  4.3  Architect  Implementation  of  the  OCU  Model 


This  figure  shows  that  an  application  controls  one  or  more  subsystems,  subsystems 
control  one  or  more  primitives  and/or  subsystems  (shown  by  the  circular  association  “con¬ 
trols”  ) ,  and  a  subsystem  is  connected  to  one  or  more  (possibly  including  itself)  subsystems 
through  import/export  connections.  An  application  or  subsystem  can  control  several  sub¬ 
systems/primitives,  but  eeich  subsystem/primitive  can  only  be  controlled  by  one  applica¬ 
tion  or  subsystem.  The  export  of  one  subsystem  can  be  connected  to  several  imports  of 
other  subsystems,  but  each  import  can  only  be  connected  to  one  export. 

There  Eire  several  differences  between  this  model  and  the  OCU  model  described 
in  (20).  Here,  an  application  object  is  specified  and  has  an  update  Edgorithm.  The  Stabi¬ 
lize,  InitiEilize,  and  Configme  procedures  for  a  subsystem  Eire  not  implemented  at  this  time 

*The  object  modeling  notation  used  for  this  figure  is  defined  in  (16). 
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and  are  areas  for  future  research®.  The  controller  function  of  the  subsystem  is  contained 
in  the  update  algorithm.  Ob'ects  are  renamed  to  primitives.  The  create  and  destroy 
procedures  for  subsystems  and  primitives  are  not  needed  since  the  REFINE  object  beae  is 
persistent  between  executions  (these  objects  do  not  need  to  be  recreated  in  the  object  base 
every  time  the  application  is  executed).  The  attributes,  current.state,  and  constants  for 
an  object  are  all  implemented  as  attributes  in  the  primitives.  Also,  a  description  and  icon 
were  added  to  applications,  subsystems,  and  primitives  to  allow  domain  visualization  and 
a  method  for  the  Domain  Engineer  to  pass  information  about  the  primitives  to  the  Appli¬ 
cation  Specialist.  The  differences  that  most  affect  this  research  are  the  lack  of  the  Initialize 
procedure  for  subsystems  and  the  implementation  of  object  attributes,  current..state,  and 
consteints  as  primitive  attributes;  these  differences  will  be  discussed  in  detail  in  the  next 
chapter. 


Figure  4.4  Primitive  Data-Flow  Diagram 

Figure  4  4  shows  a  data-flow  diagraun  for  a  primitive.  Note  that  a  primitive  cjin 
change  its  own  Attributes  through  the  update  algorithms.  The  Input-Data  is  provided 
through  the  connections  to  other  primitives  (i.e.  it  is  copied  out  of  other  primitive’s 
Output-Data).  The  SetState  procedure  cem  modify  3m  object’s  Attributes  directly,  while 
the  SetFunction  procedure  changes  which  Update- Algorithm  the  primitive  uses  to  update 
its  state®.  The  SetFunction  procedure  can  also  be  used  to  change  the  values  of  the  Coeffi- 

Architect,  the  imports  and  exports  aie  actually  implemented  as  separate  objects  with  associations 
tying  them  to  their  subsystems,  but  that  is  not  important  at  this  level  of  abstraction. 

®In  his  research,  Welgan  added  the  capability  for  Architect  to  execute  time-driven  and  event-driven 
applications.  When  using  this  capability,  each  primitive  must  have  its  own  SetState  procedure,  and  it  is 
this  procedure,  not  the  Update-Algorithm,  that  modifies  the  Attributes  and  sets  the  Output-Data.  It  can 
also  subsume  some  or  all  of  the  functionality  of  the  Update- Algorithm. 
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dents.  The  Input-Data  is  supplied  by  the  subsystem  from  its  imports  and  the  output  data 
is  incorporated  into  the  subsystem’s  exports. 

4.2.3  Creating  an  Application.  Figure  4.5  shows  the  main  control  panel  of  AVSI. 
The  buttons  on  the  upper  portion  provide  access  to  Architect’s  capabilities,  while  the 
Message  Window  reports  success  or  failiure  (with  error  messages)  of  attempted  operations 
along  with  other  helpful  information.  Each  of  the  buttons  bring  up  other  windows  to 
Eiccomplish  its  mission. 
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Figiure  4.5  The  Architect  Control  Panel 


An  application  is  built  by  adding  subsystems  to  it  and  then  building  each  of  those 
subsystems.  An  example  of  the  windows  used  to  choose  primitives  to  compose  a  subsystem 
is  shown  in  Figttre  4.6.  The  window  on  the  right  shows  the  available  primitives  for  the 
chosen  domain  (in  this  case  the  digital  circuits  domain^);  the  window  on  the  left  shows 
the  current  subsystem  (in  this  case  a  subsystem  that  provides  an  exclusive-or  functionality 
using  four  NAND  gates).  Primitives  are  added  to  the  subsystem  by  simply  moving  them 
(with  a  mouse)  from  the  right  window  to  the  left.  Subordinate  subsystems  can  also  be 
added  in  the  left  window  (through  a  menu).  It  is  important  to  note  the  ease  of  adding 
primitives  and  subsystems  to  applications-it  only  takes  a  few  clicks  on  the  mouse. 

^Information  on  the  digital  circuits  domain  implementation  in  Architect  is  contained  in  (3). 


4-7 


o 


Figure  4.6  XOR  Primitives  and  Circuits  Domain  Technology  Base 


After  subsystems  and  primitives  are  added  to  an  application,  the  connections  be¬ 
tween  the  subsystem/primitives  need  to  be  captured.  The  Application  Specialist  specifies 
these  connections  in  two  steps:  connections  between  primitives  in  the  same  subsystem  and 
connections  between  subsystems.  An  example  of  the  method  for  the  first  step  is  shovm  in 
Figure  4.7.  Note  that  proper  positioning  of  the  primitive  icons  in  this  screen  can  provide 
a  visual  cue  to  the  function  of  this  subsystem  (in  this  cetse,  w  “exclusive  or”). 

Finally,  the  update  algorithms  for  the  application  and  all  subsystems  need  to  be  spec¬ 
ified.  This  specification  is  also  accomplished  in  a  visual  enviroiunent*.  These  algorithms 
control  the  order  that  the  update  functions  of  all  subordinate  subsystem/primitives  are 
ceilled  (edong  with  two  other  functions,  SetState  and  SetFunction,  that  will  be  explained 
later).  Conditional  (if)  and  looping  (while)  statements  can  be  included  in  these  algorithms. 

*See  (9)  for  more  information  on  how  update  algorithms  are  specified. 
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Figure  4.7  XOR  Internal  Connections 


4-3  Technology  Base  Population  Methodology  for  Architect 

Now  that  Architect  has  been  briefly  explained,  the  instantiation  of  the  generic  Knowl¬ 
edge  Base  Population  process  described  in  Chapter  III  can  be  presented.  This  ins  .ntiation 
is  shown  in  Figure  4.8. 

4-3.1  Domain  Analysis.  The  most  obvious  change  in  this  figure  from  Figure  3.4 
is  that  activities  one  and  two  are  “grayed  out”  along  with  their  properties  (inputs,  outputs, 
methods,  and  constraints).  They  are  grayed  out  because,  as  stated  in  Chapter  III,  these 
two  activities  comprise  the  Domsiin  Analysis  process,  which  is  independent  of  a  particular 
DOACS  (in  this  case  Architect).  Since  these  activities  are  independent,  there  should  be  no 
changes  to  them  or  their  properties  during  the  instantiation  of  the  process  for  a  psui:icular 
DOACS. 

Actually,  the  whole  generic  knowledge  base  population  methodology  is  designed  to  be 
instantiated  for  a  pairticular  domain  zmalysis  method  and  DOACS.  However,  the  indepen¬ 
dence  between  the  domain  analysis  and  domain  implementation  phases  of  this  methodology 
allows  us  to  instantiate  activities  three,  four,  and  most  of  five  for  a  given  DOACS  inde¬ 
pendent  of  any  particulcir  domain  analysis  method,  while  activities  one,  two,  and  part  of 


Figure  4.8  Technology  Base  Population  Process 

five  can  be  instantiated  for  a  given  domain  anedysis  method  independent  of  any  particular 
DO  ACS  (actually,  this  is  easier  said  thw  done,  as  explained  in  the  next  chapter).  In  this 
chapter,  we  only  discuss  the  instantiation  of  this  methodology  for  a  particular  DOACS, 
namely  Architect. 

Different  domain  analyses  approswdies  can  be  used  to  implement  different  domains 
in  the  sEune  DOACS,  resulting  in  different  instantiations  of  activities  one  and  two.  In 
fact,  the  domain  analysis  approach  used  should  be  chosen,  at  least  in  part,  based  on  the 
characteristics  of  the  domain  to  be  analyzed.  Another  basis  for  whidi  approach  to  choose  is 
the  availability  of  automated  domain  analysis  tools  that  implement  different  approaches. 
The  ideal  situation  would  be  to  have  an  automated  tool  for  domain  analysis,  and  then 
create  another  tool  that  would  transform  the  outputs  of  this  domain  analysis  tool  into  the 
form  required  by  the  DOACS  knowledge  base  imder  consideration.  The  domain  analysis 
approach  used  for  this  research  is  described  in  Chapter  V  along  with  the  implementation 
of  a  particular  domain. 
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As  the  software  engineering  community  continues  to  investigate  domain  analysis, 
standardized  formats  and  automated  tools  to  generate  domain  information  in  these  for¬ 
mats  should  appear.  One  prototype  domain  analysis  tool  is  OORA  (Object-Oriented  Re¬ 
quirements  Analysis)  Automated  Knowledge  System  (OAKS)  (10).  OAKS  was  designed 
to  capture  domzdn  information  without  regard  to  any  particular  DOACS.  Using  this  tool, 
the  Domain  Expert  defines  object  classes  and  the  interrelationships  between  these  classes; 
the  advantage  is  that  OAKS  then  checks  the  consistency  and  completeness  of  the  entered 
information  and  displays  any  problems  found. 

4 -3.2  Domain  Implementation  in  Architect.  Activities  three  and  four  comprise 
the  domain  implementation  process  and  are  instantiated  for  Architect  in  Figme  4.8.  The 
next  two  sections  describe  these  activities. 

4.3.2. 1  Implement  Domain  Model.  Activity  three  in  Figiure  4.8  is  the  first 
step  in  implementing  a  domain  in  Architect.  This  activity  implements  the  structure  of 
the  domain  in  the  Technology  Base.  Currently,  the  Software  Engineer  accomplishes  this 
activity  by  creating  text  files.  There  is  ongoing  reseeurch,  described  in  (7),  to  populate 
the  Technology  Base  from  a  database  which,  if  implemented,  will  change  the  form  of  this 
activity.  The  type  and  amount  of  required  information  to  implement  a  domain  model  will 
not  cheinge,  but  the  method  in  which  this  information  is  input  will  change  (i.e.,  filling  in 
database  forms  instead  of  editing  text  files). 

There  zure  two  constraints  to  the  Implement  Domain  Model  activity.  The  first  is 
Architect’s  Technology  Base  structure.  This  constraint  imposes  the  format  for  domain  in¬ 
formation  that  the  Technology  Base  requires  and  requires  that  the  implementation  be  ac¬ 
complished  using  the  REFINE  language.  The  second  constraint  is  the  Design  Requirements 
placed  on  domains  implemented  in  Architect.  Two  examples  of  these  Design  Requirements 
for  Architect  are  the  OCU  model  and  the  file  structure  conventions  listed  in  Appendix  C. 
More  examples  of  these  two  constraints  are  described  later  in  this  section,  starting  with 
the  Refine  domain  model. 
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A  domsdn  model  in  REFINE  is  defined  in  (34)  as  a  class  structure  with  attributes; 
the  domain  specific  language  (DSL)  and  visual  specification  language  (VSL)  (outputs  of 
activity  three  in  Figure  4.8  are  called  grammars  and  are  not  considered  part  of  Refine 
domain  model.  Oiu:  definition  of  a  domain  model  in  Chapter  III,  however,  does  include 
the  DSL  and  VSL.  In  this  section,  as  well  as  in  Figure  4.8,  we  will  use  the  words  “Refine 
domain  model”  to  differentiate  between  these  two  uses  of  the  term  domain  model. 

Refine  Code  Required  to  Implement  a  Domain  in  Architect.  To 
implement  a  domain  in  Architect,  the  Software  Engineer  writes  REFINE  code  to  describe 
the  domain  in  five  parts.  These  five  pieces  of  code: 

1.  declare  the  domain  model  classes 

2.  define  the  attributes  for  the  domain  classes 

3.  declare  domain-specific  types  and  functions 

4.  define  the  DSL 

5.  define  the  visual  objects  that  are  parsed  in  by  the  VSL  (we  refer  to  this  code  as 
simply  the  VSL) 

6.  declare  the  icon  objects 

The  code  that  defines  the  REFINE  domain  model  classes  for  the  Digital  Logic  domain 
is  shown  in  Figure  4.9.  The  primitive  classes  are  capitalized  to  highlight  them.  Primitives 
in  Architect  are  created  from  these  classes.  The  three  intermediate  classes  (Gates,  Input- 
outputs,  and  Common-Circuits)  are  not  strictly  needed;  all  the  primitive  classes  could 
be  direct  subclasses  of  Circuits.  However,  they  do  provide  grouping  information  for  the 
primitives  when  they  are  displayed  in  the  domain  Technology  Base  window  (see  the  right 
half  of  Figme  4.6).  Also,  they  aid  in  imderstanding  the  structure  of,  and  logical  groupings 
in,  the  domain.  For  example,  it  is  easy  to  visualize  an  object  model  tree  like  Figure  4.10 
from  this  code.  In  this  figure,  the  link  between  classes  denotes  generalization  (the  upper 
class  is  a  generalization  of  the  lower  classes)  with  inheritance  (16).  In  Architect,  primitives 
can  only  be  instantiated  from  leaves  in  a  tree  like  this  one  (this  is  an  example  of  the  Design 
Requirements  constraint  shown  in  Figure  4.8  for  activity  three). 
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Tftr 

Cireaits 

:  objact-elasa  mbtyp«-of  Priaitlva-ObJ 

T«r 

tetM 

objact-claaa  aabtppa-of  Clreaita 

AID-GATE 

:  objact-claaa  aabtypa-oS  Gataa 

TUT 

OE-GATE 

:  objact-claaa  ambtypa-oS  Gataa  Ipria 

T«r 

■OT-GATE 

:  objact-claaa  aabtypa-of  Gataa  Xpria 

▼ftr 

■AID-GATE 

:  objact-claaa  aabtypa-ol  Gataa  Xpria 

var 

lOE-GATE 

:  objact-claaa  aabtypa-of  Gataa  Xpria 

▼ar 

laput-Oatpat  : 

objact-claaa  ambtypa-of  Circaita 

var 

SNITCH 

:  objact-claaa  aabtypa-of  lapat-Oatpat  Xpria 

var 

LED 

:  objact-claaa  aabtypa-of  lapat-Oatpat  Xpria 

▼ar 

CoaBon-Circnits 

:  objact-claaa  aabtypa-of  Circaita 

var 

CODITEE 

:  objact-claaa  aabtypa-of  Coaaoa-Circaita  Xpria 

var 

DECODEE 

:  objact-claaa  aabtypa-of  Coawoa-Circaita  Xpria 

var 

HALF-ADDEE 

:  objact-claaa  aabtypa-of  Coaaoa-Circaita  Xpria 

var 

JK-FLIP-FLOP 

:  objact-claaa  aabtypa-of  Coaaoa-Circaita  Xpria 

var 

MUZ 

:  objact-claaa  aabtypa-of  Coaaoa-Circaita  Xpria 

Figure  4.9  Architect’s  domain  class  code  for  the  Digital  Logic  domain 


The  Refine  domain  model  is  not  complete,  however,  until  the  attributes  of  these 
classes  are  defined.  Although  inheritance  is  included  in  the  REFINE  object  base.  Architect 
requires  that  all  attributes  be  pushed  down  to  the  primitive  class  level.  Therefore,  any 
attributes  identified  in  the  domain  analysis  for  intermediate  classes  must  be  repeated  in 
the  lower  classes.  The  code  that  implements  attributes  for  the  And-Gate  class  is  shown 
in  Figure  4.11.  Each  primitive  class  is  required  to  have  a  Refine  attribute  (implemented 
with  the  ‘*map’’  structure)  called  Coefficients  to  implement  the  coefficient  part  of  the  OCU 
model  (different  from  OCU  attributes).  The  rest  of  this  code  implements  the  attributes 
identified  during  the  domain  analysis  for  the  And-Gate  (and  all  higher  classes). 

The  domain-specific  types  define  the  type  of  information  that  will  be  passed  between 
the  primitives  while  the  domain-specific  functions  are  functions  available  for  use  by  the 
primitives  in  their  update  functions.  One  main  use  of  a  domain-specific  function  is  to  add 
methods  to  manipulate  the  domain-specific  types.  There  are  no  domain-specific  types  or 
functions  for  the  Digital  Logic  domain,  although  more  sophisticated  domain  will  probably 
have  some.  Examples  of  these  types  and  functions  are  presented  in  the  next  chapter  during 
the  discussion  of  the  implementation  of  DSP  domain. 
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Figure  4.10  Digital  Logic  Class  Structure 


In  this  example,  the  And-Gate  class  has  attributes  of  Delay,  Manufacturer,  Mil-Spec 
and  Power-Level.  Each  attribute  has  a  type  and  default  value;  this  default  value  may  be 
modified  by  the  Application  Specialist  during  composition.  Each  attribute  can  also  have 
a  description  (the  text  in  quotes  above  the  attributes)  that  provides  information  to  the 
Application  Specizdist  when  he/she  is  changing  the  value  of  that  attribute.  Each  primitive 
class  zJso  has  an  attribute  called  “name”,  but  it  doesn’t  appear  here  since  this  is  a  default 
attribute  for  all  REFINE  objects. 

After  establishing  the  REFINE  domidn  model,  there  are  three  more  items  that  need 
to  be  defined  for  every  domain.  The  first  is  the  Domain  Specific  Language  (DSL).  Using 
this  language  (implemented  through  a  grammar  in  Refine),  applications  can  be  written  to 
or  parsed  from  text  files.  In  fact,  the  Application  Specialist  could  specify  an  application  by 
creating  a  text  file  in  the  format  specified  by  the  DSL  and  then  use  the  REFINE  grammar 
tool  called  Dialect  to  load  the  application.  Dialect  would  read  the  file  and  create  the 
described  objects  in  the  Technology  Base*.  This  was  the  method  used  by  the  Application 
Specialist  to  enter  applications  before  AVSI  was  created;  however,  it  is  not  as  intuitive  as 
AVSI  and  requires  a  more  in-depth  understanding  of  how  Architect  works.  Figure  4.12 
shows  the  portion,  called  a  production,  of  the  Digital  Logic  DSL  for  the  And-Gate  primitive 

*An  example  of  one  of  these  text  files  is  contained  in  Appendix  B. 
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var  AID-6ATE-C0EFFICIEITS  :  oap (AID-GATE,  ••t(MJM-valM-obj)) 
compntad-naing 

AID-GATE-COEFFICIEITS(x)  -  {} 

"Th«  dalay  batvaaa  tba  tlma  tba  gata  raciavaa  ita 
inpnt  Talaaa  and  wbaa  it  sats  its  oatpat" 

▼ar  AI0-6ATE-0ELAT  :  map(AID~6ATE,  iatagar) 
coapatad-aaiag 
AID-GATE-OEUT(z)  -  0 

"Tba  naaa  of  tba  company  that  manafactarad  tba  gata" 
var  AID-GATE-MAIUFACTURER  :  map(AlD-GATE.  string) 
compatad-asing 

AID-GATE-MAlTIFACTUIlER(z)  -  "  " 

"  traa  ->  tba  gata  maats  azacting  military  spacifications 
falsa  ->  tba  gata  only  maats  IEEE  spacifications" 

▼ar  AID-GATE-MIt-SPEC?  :  map(AID-GATE,  boolaan) 
couqtatad-asing 
AID-GATE-NIL-SPEC? (z)  -  nil 

"Tba  anmoant  of  poaar  tba  gata  raqairas" 
aar  AID-GATE-POHER-LEVEL  :  map (AID-GATE,  raal) 
compntad-nsing 

AID-GATE-POHER-LEVEL (z)  -0.0 


Figiire  4.11  Attribute  code  for  the  And-Gate  primitive  class 
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And-Gata-Obj  [“and-gat*”  aana 

{["dalay:"  and-gata-obj-dalay] 

[([“ia  Bil-apac"  !!  and-gate-obj-mil-apac?]  1 
[''not  mil-apac"  '!!  aad-gata-obj-adl-apac?])] 
["maaalactnrar : “  and-gata-ob j -maanlacturar] 
["povar  laval:"  aad-gata-obj-poaar-laval]  }  ] 
bnilda  Aad-Gata-Obj 


Figure  4.12  And-Gate  portion  of  the  DSL 


cl2iss.  Comparing  this  production  with  the  attributes  for  the  And-Gate  cIms  shows  that 
the  DSL  does  not  add  any  more  information  above  that  provided  by  the  REFINE  domain 
model-the  attributes  of  the  primitive  class  are  just  repeated  in  a  different  form.  This  is 
the  case  for  all  primitive  classes  implemented  in  Architect. 

The  second  item  that  needs  to  be  defined  is  a  file  that,  when  parsed  in  through 
the  grsunmar  that  implements  Architect’s  Visual  Specification  Language  (VSL),  creates 
the  visued  specification  objects  that  AVSI  requires  to  memipulate  domain  primitives.  The 
acronym  VSL  is  used  (imprecisely)  to  refer  to  this  code,  although  this  code  is  really  parsed 
through  the  already  defined  VSL  grammar  (a  permanent  part  of  Architect  and  not  shown 
here).  This  VSL  is  used  to  load  the  information  necessary  to  visualize  the  domain.  An 
example  of  the  portion  of  the  Digital  Logic  file  parsed  by  the  VSL  that  implements  the 
And-Gate  primitive  cIms  visualization  is  shown  in  Figure  4.13.  The  “Icon”  section  shown 
in  this  figure  is  the  same  for  every  primitive,  except  for  “and-bitmap-1”  and  “and-bitmap- 
s”  which  are  the  specific  names  of  the  icon  objects  for  this  primitive.  The  Edit  section 
lists  the  attributes  of  the  primitive  class  whose  values  can  be  chainged  by  the  Application 
Specialist  (the  attributes  for  the  And-Gate  primitive  class  were  defined  in  Figure  4.11).  H 
zin  attribute  is  not  listed  in  this  section,  then  this  attribute  will  not  be  listed  when  the 
Application  Specialist  selects  the  menu  choice  that  eillows  the  values  of  attributes  of  a 
primitive  to  be  changed.  The  decision  whether  or  not  to  enter  primitive  class  attributes 
in  this  section  is  based  on  information  provided  by  the  Domain  Expert  diiring  Domain 
AneJysis;  in  other  words,  the  Domain  Expert  must  specify  which  attributes  the  Application 
Specialist  should  be  able  to  change. 
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attrib«tu  t«r  ilD-OATE  arc 
Icon  : 

lab«l  >  clus-aad-UM; 
clip-icoa-l«b«lT  >  falsa; 
bordar'tklckaasa  ■  0; 
bita^4icoa-l  ■  asd-bitaap-l ; 
bita^4icoa-s  ■  asd-bitaap-s 
Edit  : 

naaa  :  ayabol; 
daisy  :  lat^ar; 

■aaafactarar  :  atriag; 
■il-spac?  :  boolaaa; 
poaar-lasal  :  raal 

and; 


Figure  4.13  And-Gate  portion  of  the  VSL  spec 


The  third  item  that  needs  to  be  defined  for  every  domain  is  the  icon  object  definitions. 
Architect  creates  the  icons  it  uses  from  bitmaps,  which  are  pixel-by-pixel  representations 
of  a  graphic.  The  only  information  needed  for  these  definitions  is  the  icon  object  names 
(matching  the  ones  entered  in  the  Edit  section  described  above)  and  the  file  names  for  the 
icon  bitmaps.  The  portion  of  the  code  that  creates  these  icon  objects  for  the  And-Gate  is 
shown  in  Figure  4.14. 


var  and-bitmap-l  :  any-typa  >•  (ch:  :raad-bitB^(  "CIRCUrTS-TECH-BiSE/andgata.icoa-l'')) 

Tar  and-bitmap-s  :  any-typa  -  (c«:  :raad-bitBap(  "CnCOrTS-TECH-BASE/andgata.icoa-a")) 


Figme  4.14  And-Gate  primitive  class  icon  object  definitions 


4.3. 2. 2  Create  Primitive  Classes.  After  the  domain  model  is  implemented 
as  described  above,  the  primitives  need  to  be  implemented.  This  implementation  is  activity 
four  in  Figure  4.8.  In  this  activity,  the  behavior  of  the  primitives  will  be  implemented  in 
an  executable  form.  It  is  these  behaviors  that  describe  the  functionality  of  the  domain. 
As  with  activity  three,  the  Software  Engineer  currently  accomplishes  this  task  by  creating 
text  files. 

The  two  constraints  on  this  activity  (shown  by  the  two  arrows  going  into  the  top  of 
the  activity  box  in  Figure  4.8)  are  the  output  of  activity  three  and  the  requirements  of 
Architect,  Refine,  and  the  OCU  model.  The  Refine  domain  model  defines  the  names 
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of  the  primitive  classes  aind  attributes;  the  same  names  must  be  used  when  implementing 
the  primitive  classes.  An  example  of  an  OCU  model  requirement  is  that  every  primitive 
must  have  at  least  one  update  function.  Several  other  Architect,  REFINE,  and  OCU  model 
requirements  are  described  in  the  following  paragraphs. 

Refine  Code  to  Implement  Primitives.  The  information  needed  to 
implement  a  primitive  class  consists  of:  inputs  and  outputs  (name,  type,  and  category), 
a  description,  at  least  one  update  function,  and  an  icon  for  the  class.  The  first  three 
are  implemented  by  the  Software  Engineer  by  writing  Refine  code;  the  icons  are  created 
outside  of  the  Refine  environment. 

The  inputs  and  outputs  axe  the  primitive’s  interface  to  the  rest  of  the  application. 
When  a  primitive  is  updated,  it  tahes  the  current  values  of  the  inputs,  along  with  the  values 
of  the  coeflicients  and  attributes,  and  uses  the  specified  update  function  to  calculate  the 
outputs  (see  Figure  4.4);  the  update  function(s)  encapsulate  the  behavior  of  the  primitive. 
The  icon,  which  has  two  sizes  (large  and  small),  provides  a  visual  cue  for  the  function  of 
the  primitive  class,  as  well  as  a  method  to  use  the  mouse  to  add  new  primitives  to  an 
application.  The  icons  for  the  Digital  Logic  domain  were  shown  in  Figure  4.6. 

Figure  4.15  shows  the  portion  of  code  that  implements  the  And-Gate  primitive  class. 
This  code  is  separated  into  three  parts:  inputs  eind  outputs,  primitive  class  description, 
2ind  update  function.  The  description  can  be  viewed  by  the  Application  Specialist  diuring 
the  composition  process.  The  description  for  the  And-Gate  piimitive  is  intuitive,  but  in 
more  complicated  primitives  the  description  can  provide  the  Application  Specialist  with 
useful  information,  including  design  information  that  ^lfFects  how  the  primitive  behaves. 
There  is  only  one  update  function  for  the  And-Gate  primitive  class,  called  Updatel,  but 
if  more  than  one  existed  it  would  be  listed  here.  The  last  few  lines  in  this  figure  set  the 
default  update  function;  this  default  can  be  ch^lnged  by  a  SetFunction  statement  in  the 
parent  subsystem’s  update  algorithm  during  execution. 

The  icons  for  primitive  classes  are  currently  mzule  from  bitmaps;  the  large  fi-om  a 
64x64  bitmap  and  the  smzill  from  a  32x32  bitmap.  The  Software  Engineer  creates  these 
bitmaps  using  any  drawing  tool  that  will  output  these  sizes  of  bitmaps;  therefore,  this 
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Xispnts/ontpnts - 

v«r  MD-GlTE-OBJ-IIPDT-DiTi  :  ••t(iaq>ort-obj)  • 
{••t-attra  (maka-ob jact ( * iaport-obj ) , 
’import-aama,  *ial, 
’laport-catagory,  ‘sigaal, 
’iaport-typa-data,  'boolaaa), 

sat -attra  (maka-ob j  act ( * iaport-ob j ) , 
’utport-aaata,  *ia2, 

’import -catagorp.  ’sigaal, 

’ import -typa-data,  ’boolaaa)} 

Tar  AID-GATE-OBJ-OtTTPtrr-DATi  :  aat(azport-obj)  • 
{sat-attra  (maka-objact(’azport-obj) , 
’azport-aama,  ’ontl, 
’azport-catagory,  ’sigaal, 
’axport -typa-data,  ’boolaaa)} 


Xsat  dascriptioa- 


form  sat-aad-gata-dascriptioa 

ra:  :zl-dociimaatatioa(fiad-objact(’ra;  :biadiag,  ’AID-GATE-OBJ))  <- 
"Tha  aad  gata  takas  two  iapnts  aad  coobiaas  tbam  togatbar  (aftar 
tha  appropiata  dalay  tima)  as  follows: 


II 


iapatl 


iapat2 


output 


T 

T 

F 

F 


T 

F 

T 

F 


T 

F 

F 

F 


Xupdata  fuactioas - 

fuactioa  AID-GATE-OBJ-UPDATEl  (subsystas  :  subsystem-obj , 

aad-gata  :  AVD-GATE-OBJ)  - 

1st  (ial  :  boolaaa  >  gat-import (’ial,  subsystem,  aad-gata), 
ia2  ;  boolaaa  ■  gat- import (’ia2,  subsystem,  aad-gata), 
the-output  :  boolaaa  •  falsa) 


tbe-output  <-  ial  A  ia2: 

sat-ezport (subsystem,  aad-gata,  ’ontl,  tha-outpnt) 

Xothar  update  functions  here,  if  any 

Tar  AID-GATE-OBJ-UPDATE-FiniCTIOl  :  map (AID-GATE-OBJ,  symbol) 
cMoputad-usiag 

AID-GATE-OBJ-DPDATE-FOICTIOKx)  ■  ’AID-GATE-OBJ-OPDATEl 


Figure  4.15  And-Gate  primitive  class  code 


information  needs  to  be  included  in  the  domsun  an^Jy8is  results.  The  bitmaps  currently 
used  in  Architect  were  created  by  the  OpenWindows  IconEdit  tool  shown  in  Figure  4.16. 
There  are  two  sizes  of  icons  because  Architect  windows  can  be  rescaled  to  the  smaiiler  size 
when  the  icons  stzirt  running  off  the  edge  of  the  screen.  There  are  a  few  default  icons  that 
8u:e  supplied  with  Architect  to  aid  the  Softwzure  Engineer  and  standardize  the  visualizations 
of  some  of  the  common  functions  that  appear  in  many  domains^®. 


Figure  4.16  IconEdit  tool  showing  the  And-Gate  icon 


4-3.3  Evaluate  Domain  Development.  As  described  in  Chapter  III,  in  the  Evalu¬ 
ate  Domain  Development  activity  the  Domain  and  Software  Engineers  evaluate  the  prod¬ 
ucts  they  created  during  the  other  four  ^lctivities.  Therefore,  the  instzmtiation  of  this 
process  will  depend  on  the  Domain  Ansil^sis  method  used  as  well  eis  the  Dommn  Imple- 

list  of  the  default  Architect  icons  is  contained  in  (9). 
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mentation  process  for  the  given  DOACS.  Other  inputs  into  the  instantiation  of  this  activity 
is  the  standards  of  the  orgemization  and  what  automated  tools  are  available. 

This  activity  has  one  category  of  constraints,  Test  &  Evaluation  Requirements,  which 
includes  requirements  from  the  domain  analysis  method  and  the  DOACS,  as  well  as  or¬ 
ganizational  requirements  and  automated  support  requirements.  An  example  of  a  domain 
einedysis  method  requirement  is  a  consistency  check  that  ensures  that  pJl  domain  model 
object  classes  have  a  n2une  and  that  these  names  are  imique.  An  example  of  an  organiza¬ 
tional  requirement  would  be  to  have  all  activity  outputs  reviewed  by  some  quality  control 
agent.  Architect  has  several  consistency  checking  requirements,  but  fortunately,  most  of 
them  can  be  implemented  automatically  in  REFINE.  The  most  important  non-automated 
consistency  checking  requirement  for  Architect  is  that  the  name  of  the  primitive  must  be 
appended  to  the  beginning  of  the  attribute  name  when  an  attribute  is  implemented  for  a 
primitive  (see  Figure  4.11). 

Test  &  Eveduation  tools  include  both  domain  analysis  tools  and  domain  implemen¬ 
tation  tools.  An  example  of  an  automated  domain  analysis  tool  is  OAKS  (described  in 
Section  3.3).  A  special  feature  of  OAKS  is  that  it  maintains  a  list  of  items  the  Domain 
Engineer  heis  to  enter/deconfiict  before  the  domain  is  consistent  and  complete.  An  example 
of  a  domain  implementation  tool  is  Architect’s  lest  Primitive,  described  below. 

Domain  Implementation  Evaluation.  The  evaluation  of  a  domsun 
implementation  in  Architect  consists  of  three  steps:  evaluate  the  primitives,  evaluate  the 
domain  model  and  primitive  interfaces,  amd  compare  the  domain  implementation  to  the 
dom^lin  analysis  results.  The  rest  of  this  section  describes  these  three  steps. 

As  mentioned  above.  Architect  has  a  tool  to  help  evaJuate  individual  primitives, 
which  WM  implemented  as  a  pairt  of  this  research  effort.  This  tool,  called  Test  Primitive, 
is  intended  for  use  by  the  Software  Engineer  in  testing  individual  primitives.  It  is  provided 
on  the  Architect  Control  Panel  for  ease  of  use  in  this  reseeirch  environment,  but  would 
be  removed  if  Architect  was  to  be  installed  at  a  production  site  since  use  of  this  function 
should  not  be  provided  the  the  Application  Specialist. 
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In  Test  Primitive,  the  Software  Engineer  can  choose  an  individual  primitive  and  test 
its  update  fimction(s).  This  is  accomplished  by  providing  windows  in  which  the  Software 
Engineer  C2m  change  the  values  of  the  primitives  attributes,  inputs,  and  current  update 
function  directly,  execute  the  primitive’s  specified  update  fimction,  and  then  display  the 
produced  outputs.  Of  course,  the  use  of  this  tool  does  not  help  if  the  Software  Engineer 
does  not  have  correct  sample  data  to  comp“je  to  the  Test  Primitive  results;  in  other  words, 
he/she  must  know  what  outputs  to  expect,  or  he/she  will  not  know  if  they  are  correct. 
This  sample  data  should  be  compiled  by  the  Domain  Engineer.  An  example  of  the  use  of 
the  Test  Primitive  tool  is  discussed  in  section  5.5.2. 

Although  Architect  does  not  have  any  specific  tools  to  evaluate  the  dommn  model  and 
primitive  interfaces,  the  easy  prototyping  and  execution  capability  of  Architect  provides  a 
simple  and  convenient  way  to  test  them.  After  each  individual  primitive  has  been  tested, 
the  Software  and  Domain  Engineers  should  compose  some  simple  applications  to  test  the 
interfaces  between  the  primitives.  It  is  impossible  to  compose  all  possible  applications 
(since  there  are  an  infinite  number  of  them),  but  enough  should  be  implemented  so  that 
every  primitive  has  been  used  and  the  Engineers  feel  confident  that  the  domain  semantics 
have  been  implemented  correctly.  During  the  composition  and  execution  of  these  simple 
applications,  the  Software  and  Domsun  Engineers  evaluate  the  domain  structure  eis  a  whole, 
looking  for  things  like  missing  primitives,  conflicting  primitives,  primitives  that  overlap  in 
functionality,  etc. 

Although  there  are  many  parts  of  the  Evaluate  Domain  Development  £M:tivity  that 
can  be  cleaxly  specified  (such  as  specific  consistency  checks  and  automated  tools  described 
above),  the  Softwzure  zmd  Dommn  Engineers  should  take  a  step  back  from  the  specific 
activities  of  this  process  and  look  at  the  domain  analysis  and  dornmn  implementation 
products  as  a  whole.  For  the  Softwaure  Engineer,  we  recommend  that  he/she  tzJce  the  time 
to  sit  down  with  the  domain  analysis  and  domain  implementation  results  and  compare 
them.  He/she  should  not  concentrate  on  the  primitive  behaviors,  since  they  were  tested 
zJreewiy.  The  Software  Engineer  should,  however,  make  sure  the  domsdn  structinre  and 
interfaces  are  consistent  and  complete. 
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4-3.4  Reusable  Applications.  As  described  in  Chapter  III,  there  are  two  msdn 
methods  to  add  applications  into  a  knowledge  base  ais  new  primitives.  The  first  is  to 
provide  the  application  as  it  exists  (with  all  its  sub-components  and  connections)  to  the 
Application  Specizilist  2is  a  new  reusable  component  and  allow  him/her  to  compose  it  into 
new  applications  just  like  the  other  components.  The  second  is  to  feed  this  application 
back  into  the  domain  analysis  process,  abstract  out  its  functionality,  and  then  implement  a 
new  component  with  this  behavior.  The  second  method  should  be  possible  in  any  DOACS 
that  fits  into  the  G-DOACS  framework  (Figmre  3.1);  however,  the  first  is  more  consistent 
with  the  reuse  principle  of  DOACSs  (and  should  be  easier). 

We  see  the  results  of  the  second  method  in  the  Digital  Logic  domain  in  Architect. 
In  Figure  4.9  there  are  three  intermediate  classes:  Gates,  Input-Output,  and  Common- 
Circuits.  During  the  domain  analysis  process,  the  first  primitives  in  the  Gates  and  Input- 
Output  classes  were  identified.  The  primitives  in  Common-Circuits  were  not  identified 
until  later  when  the  domain  had  been  in  use  for  some  time.  In  fact,  the  fimctions  of  the 
primitives  were  first  built  into  applications  by  using  the  original  set;  then,  as  it  became 
apparent  that  the  functions  of  these  applications  would  be  used  over  and  over,  the  functions 
of  these  reusable  applications  were  implemented  as  individual  primitives. 

Architect  cannot  implement  reusable  applications  using  the  first  method  (although 
there  is  a  method  that  is  somewhat  similar  using  what  are  C2dled  generics  (33)).  A  better 
way  to  implement  the  primitives  in  the  Common-Circuits  would  have  been  to  build  them 
into  a  subsystem,  test  this  subsystem,  emd  then  make  it  available  to  the  Application 
Specialist  as  a  new  reusable  component.  This  capability  could  be  easily  added  to  Architect; 
however,  it  would  need  to  be  integrated  with  the  new  data  base  implementation  of  the 
Technology  Base  being  developed  as  a  part  of  (7). 

4-4  Summary 

The  purpose  of  this  chapter  was  to  provide  a  formal  method  for  implementing  a 
dommn  in  Architect.  This  was  accomplished  by  (after  a  brief  description  of  Architect 
and  its  use  of  the  OCU  model)  instantiating  the  general  population  method  presented  in 
Chapter  III.  This  method  includes  implementing  the  domain  model  sind  then  implementing 
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the  individual  primitive  classes.  These  two  activities  are  followed  by  a  feedback  loop  in 
which  the  primitives  and  the  domain  as  a  whole  are  evaluated  and  compared  to  the  domain 
zui2dysis  results,  fixed,  and  verified  and  validated.  Also,  this  feedback  loop  provides  for  the 
evolution  of  both  the  domain  analysis  results  and  the  domain  implementation. 
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V.  Implementing  the  Digital  Signal  Processing  (DSP)  Domain  in  Architect 

5. 1  Introduction 

In  this  chapter  we  discuss  the  analysis  and  implementation  of  the  Digital  Signal  Pro¬ 
cessing  (DSP)  domain  accomplished  as  a  part  of  this  research  effort.  We  implemented  the 
DSP  domain  in  Architect  to  validate  the  Architect  instantiation  (presented  in  Chapter  IV) 
of  our  generic  knowledge  base  population  methodology  (presented  in  Chapter  III) .  There 
are  several  reasons  for  this  discussion:  to  show  an  example  of  domain  analysis,  to  show 
an  actual  Architect  domain  implementation,  and  to  provide  a  forum  for  explziining  some 
details  and  problems  of  implementing  a  domain  in  Architect. 

This  chapter  is  organized  along  the  lines  of  the  population  methodology  in  Figiire  4.8; 
domain  analysis,  domzdn  implementation,  and  domain  evaluation  of  the  DSP  domain  are 
discussed  in  that  order,  each  in  a  separate  section.  The  final  section  describes  errors  in 
the  Architect  system  that  affect  the  implementation  and  use  of  the  DSP  domain.  First, 
however,  we  will  provide  a  brief  definition  of  the  DSP  domain. 

5.2  The  DSP  domain 

“Digital  Signal  processing  deds  with  the  representation  ot  signals  as  ordered  se¬ 
quences  of  numbers  ^lnd  the  processing  of  those  sequences”  (37:1).  These  signals  are  not 
always  the  typical  electro-magnetic  r{idiation,  like  radio  signals,  that  first  comes  to  mind; 
they  can  come  from  smything  measurable,  like  temperature  samples,  the  number  of  stars 
visible  every  midnight,  or  how  long  it  takes  to  get  dressed  every  morning.  Each  element 
of  a  signal  is  called  a  sample;  a  signal  consists  of  an  ordered  sequence  of  samples.  Signals 
can  consist  of  real  or  imagineiry  numbers,  £md  can  be  multidimensional  (i.e.,  a  sample  can 
contain  more  tham  one  number,  but  all  samples  in  a  signal  must  be  the  same  size).  IVpi- 
cal  fields  in  which  DSP  has  played  a  major  role  include  speech  and  data  conununication, 
biomedical  engineering,  acoustics,  sonar,  radar,  seismology,  oil  exploration,  instnimenta- 
tion,  robotics,  eind  consumer  electronics,  junong  many  others  (29:1).  Typical  reasons  for 
processing  these  sequences  of  munbers  include:  estimation  of  characteristic  signal  parame- 
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ters,  elimination  or  reduction  of  unwanted  interference,  emd  transformation  of  a  signal  into 
a  form  that  is  in  some  sense  more  informative  (37). 

5.S  Domain  Analysis 

Since  our  work  concentrates  on  domain  implementation,  the  specific  method  we  used 
to  analyze  the  DSP  domain  is  not  particularly  important  to  this  research.  However,  it 
is  briefiy  discussed  here  for  four  reasons.  First,  presentation  of  our  DSP  domain  analysis 
process  shows  how  the  domain  model  and  component  specifications  (the  domain  analysis 
outputs  from  Figure  3.4)  are  created  so  that  they  can  be  used  in  the  domain  implementation 
process.  Second,  the  domain  analysis  methodology  presented  here  is  particularly  useful  in 
generating  these  outputs  in  a  form  that  can  be  easily  used  in  the  domain  implementation 
process  for  Architect.  Third,  even  though  identifying  a  particular  domain  analysis  method 
is  not  important  to  this  research,  an  example  of  a  domain  analysis  process  is  helpful  in 
understanding  how  to  populate  Architect’s  Technology  Base.  And  finally,  we  present  the 
domain  analysis  method  we  used  to  help  show  specific  cases  where  the  separation  of  the 
domain  analysis  process  from  a  particular  DOACS  is  not  always  best. 

5.3.1  The  Independence  Between  Domain  Analysis  and  a  Domain  Implementation. 

Diuing  the  discussion  of  our  generic  knowledge  base  population  methodology  in  Chap¬ 
ter  III,  we  proposed  that  activities  1  and  2  in  Figure  3.4  (which  comprise  the  domain 
analysis  process)  should  be  independent  of  a  particular  DOACS  (see  Section  3.3.2).  How¬ 
ever,  based  on  the  results  of  om  resecirch,  we  conclude  that  this  independence  of  domain 
ansdysis  and  domain  implementation  ceumot  always  be  accomplished  and,  even  if  it  could, 
it  might  not  be  the  most  efficient  method. 

In  Section  3.3  we  compared  the  division  between  domain  walysis  and  domain  im¬ 
plementation  to  the  division  between  the  front  wd  back  ends  of  a  compiler.  This  works 
well  during  compiler  generation  because,  while  there  is  not  a  single  intermediate  language, 
there  are  a  few  standardized  ones;  and  these  standard  intermediate  languages  have  the 
same  basic  functionality.  The  results  of  a  domain  analysis,  however,  are  not  fully  un¬ 
derstood,  much  less  standardized.  We  believe  that  when  domain  analysis  becomes  more 
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fully  imderstood  and  standardized,  it  can  be  separated  from  domain  implementation  as  we 
propose  (similar  to  the  separation  of  the  front  and  back  ends  of  a  compiler). 

Even  if  the  technology  was  currently  available  to  implement  this  separation  between 
the  domain  analysis  and  domain  implementation  phases,  in  some  situations  complete  sep¬ 
aration  is  difficult  and  not  the  best  way  to  populate  a  knowledge  base.  For  a  small  project 
(like  this  research  effort),  one  person  may  take  on  the  roles  of  both  the  Domain  Expert 
and  the  Software  Engineer.  In  this  case,  it  is  difficult,  if  not  impossible,  for  that  person 
to  completely  ignore  his/her  Software  Engineer  responsibilities  during  the  domain  analysis 
phase.  The  two  phases  should  still  be  done  separately,  but  the  requirements  of  domain 
implementation  will  “bleed”  over  into  domain  analysis.  Also,  if  the  domain  analysis  is  only 
going  to  be  used  to  populate  one  knowledge  base,  then  it  can  be  accomplished  faster  and 
more  efficiently  if  it  is  tailored  to  meet  the  requirements  of  the  knowledge  base.  For  ex¬ 
ample,  if  the  DOACS  does  not  have  the  capability  for  domain  visualization,  then  it  would 
be  a  waste  of  time  to  collect  this  information  during  domain  analysis.  Another  example  is 
that  the  information  identified  during  domain  analysis  could  be  collected  in  a  form  based 
on  the  eu:chitecture(s)  available  in  the  DOACS.  It  is  our  opinion  that  this  could  represent 
a  significant  time  savings  during  the  population  process;  an  example  of  this  is  identified  in 
the  following  section.  In  any  case,  the  change  to  om:  methodology  to  handle  this  is  to  add 
“dommn  implementation  requirements”  as  an  input  to  activities  one  and  two  in  Figures  3.4 
and  4.8. 

5.S.S  The  Domain  Analysis  Method  Used.  For  this  effort  we  used  part  of  Mc¬ 
Cain’s  Software  Development  Methodology  for  Reusable  Components  as  the  betsis  of  oiu: 
domain  einalysis  method.  In  (25),  “a  conventional  product  development  model  is  used  as 
a  basis  for  a  methodology  for  the  construction  of  reusable  software  components”  (25:70). 
Although  his  methodology  does  not  deal  with  the  population  of  knowledge  bases,  step 
two  of  his  eight  step  process  is  a  domain  analysis  method  that  fits  well  into  our  generic 
knowledge  base  population  methodology. 

There  are  five  activities  in  this  method: 

1.  Prepare  Dommn  Information 
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2.  Define  reusable  entitira 


3.  Define  reusable  abstractions 

4.  Perform  classification  of  reusable  abstractions 

5.  For  each  component,  perform  a  component  domain  analysis 

Activities  two  through  five  are  listed  verbatim  firom  the  domain  analysis  part  of  McCain’s 
method;  activity  one  was  added  by  this  researdi.  McCain’s  method  has  an  additional 
step  prior  to  the  domain  analysis  step,  called  ‘perform  market  analysis”,  that  covers  some 
of  what  this  added  activity  entails,  but  his  method  is  oriented  towards  selling  software, 
where  we  are  more  interested  in  basic  domain  analysis.  Step  one  is  from  Prieto-Diaz’s 
method  discussed  in  Chapter  Ill-it  is  the  first  step  in  Figure  3.2  (32:67).  Note  that  the 
last  activity  in  McCain’s  method  maps  directly  onto  the  second  activity  of  our  generic 
population  method  (Figme  3.4). 

McCain  then  goes  on  to  list  the  activities  that  comprise  a  component  domain  anal¬ 
ysis  (25:74-76): 

1.  Define  abstrsKrt  interface  specification.  For  each,  identify: 

•  Name 

•  Description 

•  Allowable  values 

•  Default  value(8) 

•  Error  messages 

2.  Perform  constraint  an2dysi8  to  minimize  abstraction  constraints 

3.  Define  applicable  algorithms  and/or  existing  software 

4.  Define  customization  requirements  based  on  the  abstract  interface  specification 

5.  Define  component  visualization (s) 

Again,  these  activities  are  listed  verbatim  from  step  two  of  McCain’s  method,  except  that 
we  added  the  last  one  because  McCfun’s  process  does  not  deal  with  component  visualiza- 
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tions.  These  visualizatioiu  are  needed  to  implement  a  domain  in  Architect.  This  addition 
illustrates  how  the  DOACS’s  requirements  can  influence  the  domadn  aneilysis  method. 

As  stated  before,  this  method  fits  well  into  our  generic  knowledge  base  population 
method  and  its  output  is  in  a  form  that  can  be  easily  used  to  implement  a  dom2un  in  the 
cvirrent  version  of  Architect.  However,  as  capabilities  are  added  to  Architect,  more  and 
different  types  of  information  will  have  to  be  collected  during  the  domain  analysis  process. 
For  example,  there  are  plans  to  add  domain-specific  semantic  checks  to  Architect;  this 
a'^dition  will  require  that  domain-specific  semantic  niles  be  identified  during  the  domain 
analysis  process,  which  in-tum  requires  that  a  step  be  added  to  the  above  method  to  collect 
this  information.  If  the  state  of  the  art  was  advanced  enough  to  allow  a  standard  domain 
2inalysis  output  to  capture  everything  necesseury  in  a  domain,  then  an  addition  of  more 
domain  analysis  steps  like  this  one  would  never  be  needed. 

5.3.3  Analyzing  the  DSP  Domain.  In  this  section  we  describe  our  analysis  of 
the  DSP  domain.  This  discussion  is  organized  according  to  the  domain  analysis  method 
presented  in  the  last  section.  In  each  step,  some  examples  are  given. 

5.3.3. 1  Prepare  Domain  Information.  As  stated  in  the  previous  section,  we 
used  Prieto-Diaz’s  Prepare  Domain  Information  as  the  first  activity  in  our  domain  analysis 
method.  Prieto-Diaz  bre^lks  this  activity  down  into  five  steps;  the  first  four  are  applicable 
to  our  method  ^  (32:67): 

•  Define  Domain  Analysis  Approach:  our  domain  analysis  method  was  presented  in 

Section  5.3.2. 

•  Define  Domain:  a  description  of  the  DSP  domain  was  presented  in  Section  5.2. 

•  Bound  Domain:  we  identified  several  bounds  for  the  DSP  domain: 

1.  Discrete-time:  “A  discrete-time  system  is  defined  mathematically  as  a  transfor¬ 
mation  or  operator  that  maps  an  input  sequence  with  values  x[n]  into  an  output 

*Part  of  Prieto-Diaz's  fifth  step  is  to  consolidate  the  outputs  of  the  first  four  steps  into  a  document,  the 
rest  is  covered  in  later  activities  in  our  method. 
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sequence  with  values  y[n].  This  can  be  denoted  as  :  y[n]  =  T{x[n]}...”  (29:17). 
In  this  representation,  x[n]  and  y[n]  denote  input  and  output  signab  for  the 
operation  T.  X[i]  (where  i  is  a  specific  natural  number)  represents  the  value  of 
a  specific  value  (sample)  of  signal  x[n]. 

2.  Deterministic:  each  sample  of  a  signal  is  uniquely  specified  by  a  mathematical 
expression;  in  most  cases,  a  real  or  complex  number. 

3.  Finite-duration:  signals  are  defined  during  some  finite  time  interval  and  asstuned 
to  be  zero  outside  that  interval  (some  references,  like  (38),  assume  the  values 
outside  the  specified  time  interval  to  be  undefined,  but  this  assumption  is  harder 
to  implement  in  a  computer). 

4.  One-dimensional:  signals  have  only  one  dependent  and  one  independent  vari¬ 
able.  If  a  signal  was  composed  of  temperature  samples  over  time,  then  time  is 
the  independent  variable  and  temperatmre  is  the  dependent  variable  (from  this 
point  on  we  will  assxune  time  is  the  independent  variable,  remembering  that 
other  independent  variables  czm  be  used).  Multi-dimensional  signal  processing 
could  easily  be  added  to  the  domain  by  duplicating  each  component  and  adding 
a  “2D”  subscript  to  each  of  these  duplicated  component’s  names. 

5.  Normalized:  the  interval  between  any  two  sequential  values  of  the  independent 
veiriable  is  the  seL”ie  between  signals.  For  example,  if  the  independent  variable 
is  time,  then  two  signals  being  added  together  are  assumed  to  have  the  same 
elapsed  time  between  each  sample  of  all  signals  used  in  an  application  (for 
example,  2dl  signals  are  sampled  at  a  rate  of  three  samples  per  second). 

6.  Linear:  for  T{xi[n]}  =  yi[n]  and  T{x2[n]}  =  y2[n],  T  is  lineeu:  if 
T{xi[n]  -t-  X2[n]}  =  T{xi[n]}  -I-  T{x2[n]}  =  yi[n]  -f  y2[n]  and 

T{ax[n]}  =  aT{x[n]}  =  ay[n].  The  first  equality  is  called  the  additive  property; 
the  second  is  called  the  homogeneity  or  scaling  property.  All  operations  (and 
combinations  of  operations)  for  this  domain  model  aie  linear. 

7.  Time-invzuriant  (dso  called  shift-invariant):  a  time  shift  or  delay  of  the  input 
signed  causes  a  corresponding  shift  in  the  output  signed. 
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8.  Real:  all  signals  are  real,  eis  opposed  to  signals  that  cannot  exist  in  the  real 
world  such  as  the  exponential  signal  x[n]  =  e”  whose  values  increase  forever. 

These  bounds  are  typical  DSP  restrictions.  More  detailed  discussions  can  be  found 
in  (29)  and  (38),  among  others. 

•  Select  Knowledge  Sources: 

1.  Existing  Systems:  the  three  we  foimd  most  useful  were  Khoros  (40),  PCDSP  (2), 
and  MatLab  (21).  The  Joint- Modeling  and  Simulation  System  project  (6)  is 
developing  DSP  components,  but  we  only  had  access  to  a  portion  of  the  Ada 
code.  No  documentation,  descriptions,  or  domain  amalysis  results  were  avmlable. 
From  this  code,  it  appears  that  during  the  domciin  analysis  process  the  DSP 
components  were  captured  in  a  form  that  would  facilitate  implementation  in 
Architect  (in  the  code  each  DSP  component  is  implemented  in  its  own  package, 
with  inputs,  outputs,  attributes,  and  an  update  function  just  like  in  Architect). 
However,  even  if  we  had  the  complete  set  of  J-MASS  DSP  Ada  code,  low-level 
language  code  is  not  a  sufficient  input  for  the  Architect  domain  implementation 
process  because,  among  other  reasons,  low  level  design  decisions  are  made  in 
creating  code  which  should  not  influence  domain  analysis. 

2.  Experts:  AFIT  fewrulty  and  students  conducting  DSP  research  were  consulted 
during  the  domsdn  analysis  and  domain  implementation  activities. 

3.  Existing  Documentation:  sever^ll  texts  on  DSP  were  used.  The  most  helpful 
were  (29),  (38),  (11),  (19),  (24),  and  (30). 

5. 3. 3. 2  Define  Reusable  Entities  and  Abstractions.  In  this  activity,  reusable 
entities  and  reusable  abstrjictions  are  identified  and  defined.  “Reusable  entities  are  those 
entities  for  which  a  collection  of  related  independently  selectable  reusable  components  may 
be  defined... Reusable  abstractions  identify  candidate  independently  selectable  reusable 
components”  (25:74).  In  simpler  terms,  the  reusable  abstractions  are  the  components  of 
the  domeiin  that  will  be  used  in  composing  applications,  while  the  reusable  entities  are 
generalizations  (higher  level  classes)  of  those  components.  Although  it  is  not  apparent 
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from  McCain’s  definitions,  he  does  allow  for  midtiple  levels  of  reusable  entities  (i.e.  gener¬ 
alizations  of  generalizations). 

We  have  listed  the  “define  reusable  entities”  and  “define  reusable  abstractions”  ac¬ 
tivities  together  because  not  all  object-oriented  methodologies  have  them  in  the  same  order 
as  McCain.  In  DSP  domain  analysis,  we  interleaved  these  two  activities;  in  some  psuts  of 
the  domain  we  identified  the  entities  first  emd  then  the  abstractions  for  that  entity,  and 
in  other  pzurts  we  identified  them  in  the  reverse  order.  The  results  of  this  activity  for  the 
DSP  domain  are  deferred  \mtil  the  description  of  the  next  activity. 

5.3.3. 3  Perform  Classification  of  Reusable  Abstractions.  In  the  Perform 
Classification  of  Reusable  Abstractions  ^lctivity,  the  Domain  Expert  takes  the  components 
and  generalizations  (reusable  entities  and  abstractions)  from  the  previous  activity  iind 
organizes  them  into  an  object  model  hierarchy.  During  this  activity  for  the  DSP  domain, 
we  found  the  existing  systems  listed  in  Section  5.3.3.1  to  be  particularly  useful  (they  were 
also  useful  during  the  last  activity).  We  used  them  by  extracting  their  domain  object 
model  hierarchies  and  comparing  them  to  each  other  and  our  hierarchy.  The  upper  levels 
of  these  extracted  hierarchies  (down  to,  but  not  including,  the  components  that  would  be 
the  leaves  of  these  trees)  au:e  shown  in  Figures  5.1  (40),  5.2  (2),  and  5.3  (21).  These  figures 
use  the  object  model  notation  introduced  in  Section  4.2.2. 

The  Khoros  system  (40)  was  the  most  helpful  of  the  three,  most  likely  because  Khoros 
is  a  DOACS  with  similar  capabilities  to  Architect.  It  should  be  noted  that  the  DSP  domain 
model  hierarchy  for  MatLab  includes  only  the  parts  listed  in  the  Digiteil  Signal  Processing 
Toolbox  (21);  there  are  meiny  other  parts  of  MatLab  (especially  the  arithmetic  functions) 
that  can  be  used  in  conjimction  with  this  Toolbox. 

The  domain  model  hierarchy  we  developed  for  the  DSP  domain  during  this  activity 
is  shown  in  Figmre  5.4.  In  the  interests  of  space,  the  components  are  listed  imder  each  class 
instead  of  being  shown  in  boxes  linked  to  their  parents.  In  general,  the  reusable  entities 
identified  in  the  previous  activity  become  the  interior  nodes  in  the  tree;  the  reusable 
abstractions  become  the  leaves.  In  a  domain  as  diverse  and  rapidly  changing  as  DSP, 
no  domain  model  can  possibly  include  eiU  aspects  of  the  domain.  In  this  domain  model 
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Figure  5.1  Khoros  DSP  domain  model  hierarchy 


Figure  5.2  PCDSP  domain  model  hier2u:chy 


Figxire  5.3  MatLab  DSP  domzdn  model  hierarchy 


Figure  5.4  Architect  DSP  domain  model  hierarchy 
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hierarchy,  only  a  canonical  set  of  components  have  been  identified;  there  are  many  others 
that  could  have  been  included. 

We  developed  this  domain  model  hierarchy  iteratively  (i.e.  this  is  not  the  first  hier¬ 
archy  we  developed)  by  comparing  the  information  gathered  from  the  knowledge  sources 
listed  in  Section  5.3.3. 1.  After  we  developed  our  first  full  dommn  hierarchy,  we  held  a 
mini- “design  review”  where  we  presented  our  results  to  a  domain  expert.  Figure  5.4  shows 
the  hierarchy  after  the  dommn  expert’s  suggestions  were  included. 

Figure  5.4  shows  the  domain  model  hierarchy  only;  each  item  in  this  figinre  must 
also  contciin  a  definition  and  list  of  attributes.  For  example,  the  following  definition  smd 
attributes  were  identified  for  the  Discrete  Fourier  transform  (DFT)  component: 

Name:  Discrete  Fourier  transform  (DFT). 

Description:  The  Discrete  Fourier  transform  (sometimes  called  the 

Discrete-Time  Fourier  transform  in  DSP)  converts  a  signal  from  the  time  domain  to  the 
frequency  domain.  The  independent  variable  of  the  resulting  signal  is  radians  and,  no 
matter  how  many  samples  it  consists  of,  the  first  SEtmple  is  at  0  radians  and  the  last  is 
at  27r  radians  (the  rest  are  evenly  distributed  between  this  range).  For  real  signals,  the 
output  from  0  to  tt  is  the  mirror  of  the  output  from  tt  to  2ir.  The  converse  of  the  DFT  is 
the  inverse  Discrete  Fourier  transform  (IDFT). 

Attributes:  The  DFT  only  contains  one  attribute: 

•  Name:  ScaJe-by-N?^ 

•  Type:  boolean 

•  Description:  when  true,  this  attribute  causes  each  sample  of  the  output  of  the  DFT 
to  be  scailed  (divided)  by  N,  where  N  is  the  number  of  samples  in  the  input  signal. 

^The  question  meirk  is  p2irt  of  the  name. 


5-11 


5. 3. 3. 4  Perform  Component  Domain  Analysis.  Now  that  the  domain  model 
hierarchy  has  been  created,  each  of  the  components  must  be  specified  in  more  detail.  Again, 
we  will  use  the  DFT  component  as  an  example: 

1.  Define  abstract  interface:  The  DFT  component  has  one  input: 

•  Name:  Input 

•  Description:  a  signal. 

•  Allowable  values:  any  valid  signal. 

•  Default  value(s):  none. 

•  Error  messages:  “input  signal  not  defined”  if  the  input  signal  has  not  been 
provided  to  the  DFT. 

The  DFT  component  eJso  has  one  output: 

•  Name:  Output 

•  Description:  a  signal. 

•  Allowable  values:  any  valid  signal  containing  complex  numbers. 

•  Default  value(s):  none. 

•  Error  messages:  none. 

2.  Perform  constraint  malysis:  there  are  no  constreunts  on  om  DFT  component  in 
general  (other  thm  those  on  the  domain  as  a  whole);  however,  different  algorithms 
for  computing  a  DFT  have  different  constraints.  For  example,  if  we  losed  the  standard 
Fast  Fourier  transform  (FFT)  algorithm  for  calculating  the  DFT,  the  number  of 
samples  in  the  input  signal  would  have  to  be  a  perfect  square. 

3.  Define  applicable  adgorithms:  the  DFT  is  specified  by  the  equation 

=  12n=o  where  N  is  the  number  of  samples  in  the  input  signal  and 

Wjv  (in  signal  notation,  x[n]  denotes  a  signal  in  the  time  domain  while 

X[n]  denotes  a  signaJ  in  the  frequency  domain;  the  first  sample  of  each  is  at  n=0). 
The  equalities  e^^^  =  cos(A)  ±  j  *  sin(A)  and 
useful.  One  pseudo-code  algorithm  to  implement  the  DFT  is: 
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l«t  N  b«  the  size  of  the  input  signal 
for  i  in  0  to  N-1  do 
Output (i)  ■  0 
for  j  in  0  to  N-1  do 
A  ■  (2*pi*i*j)/N 

Output(i)  ■  Output(i)  +  Input(j)  •  (cos(A)  -  j*sin(A)) 
end(for) 

if  Scale-by-N?  then 
Output (i)  ■  Output (i)  /  H 
end (if) 
end (for) 
return  Output 


4.  Define  customization  requirements:  the  DFT  component  may  be  implemented  as  two 
components,  one  that  tsdees  a  signal  of  real  samples,  and  one  that  takes  a  signal  of 
complex  samples.  The  real  sample  case  is  the  more  common.  Also,  the  attribute 
Scale-by-N?  should  be  assigned  at  run-time  to  customize  that  particular  DFT  com¬ 
ponent. 


5.  Define  component  visualization  (s):  the  DFT  component  does  not  have  a  commonly 
accepted  visualization;  however,  there  is  a  common  visualization  for  a  generic  trans¬ 
form.  Therefore,  the  DFT  component  may  be  visualized  as: 


MT 


.  There  are 


no  chamges  to  this  visualization  to  reflect  state  changes  (since  the  DFT  component 
has  no  state  other  than  the  value  of  it’s  attribute). 


Although  the  DFT  component  does  not  have  a  commonly  accepted  visuedization, 
other  components  do.  To  find  these  visualizations,  the  Domain  Expert  should  look 
for  guidemce  from  existing  systems  and  documentation  (books).  Figure  5,  which  we 
found  in  (11:373),  shows  an  example  of  the  type  of  visualization  information  that  the 
Domain  Expert  should  look  for. 


5.4  Domain  Implementation  in  Architect 

In  this  section  we  describe  our  DSP  domain  implementation  in  Architect.  This 
process  consists  of  Eictivities  three  and  four  in  the  Architect  instantiation  of  oiur  generic 
knowledge  base  population  methodology  (see  Figure  4.8).  These  activities  are  discussed  in 
the  following  two  sections. 
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Figure  5.5  Common  filter  component  visualizations 

5.4.1  Implement  Domain  Model.  Barring  any  problems  found  at  this  stage,  if 
the  domain  einalysis  is  detailed  and  consistent,  then  the  Implement  Domain  Model  activity 
of  our  process  (described  in  Section  4.3.2.1)  is  trivial.  First,  the  class  hierarchy  from 
Figure  5.4  is  transformed  into  Architect  domain  class  code.  The  code  for  the  DSP  domain 
is  shown  in  Figure  5.6. 

There  are  two  reasons  for  the  differences  between  the  classes  in  Figure  5.4  and  Fig¬ 
ure  5.6.  The  first  reason  is  that,  due  to  time  constraints,  we  decided  not  to  implement  all 
identified  components.  This  also  demonstrates  the  capability  we  discxissed  Section  3.3.1  to 
implement  a  portion  of  the  domain,  then  use  that  portion  to  generate  applications  before 
the  rest  of  the  domain  is  implemented.  The  second  reason  is  that  Figure  5.4  was  our  first 
attempt  at  structuring  the  DSP  domain;  this  structure  evolved  during  our  thesis  effort. 
The  final  structure  appears  in  Section  5.5,  where  we  compare  it  to  the  original  and  discuss 
the  differences. 

The  code  that  implements  the  domain-specific  types  and  domain-specific  functions 
is  shown  in  Figiure  5.7.  In  the  next  2ictivity,  Implement  Primitive  Classes,  one  of  the 
items  that  must  be  specified  for  each  primitive  class  is  the  type  of  the  data  being  used  in 
that  input  or  output.  If  this  information  is  other  than  one  of  the  five  basic  Refine  types 
(boolean,  integer,  resd,  string,  symbol),  then  a  domain-specific  type  must  be  defined  for  this 
information.  The  main  purpose  of  the  domain-specific  functions  is  to  provide  methods  to 
manipulate  the  dommn-specific  types,  although  any  function  that  will  be  used  repeatedly 
in  the  primitive  update  functions  should  be  defined  here. 
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var 

DSP 

:  object-class  subtype-of  Primitive-Obj 

var 

Signals  :  objsct-class  snbtypa-of  DSP 

var 

Sinusoid 

object-class  subtype-of  Signals  Xprim 

var 

Stored-Signal 

:  object-class  subtype-of  Signals 

Xprim 

var 

Unit -Sampls-Sequonce 

:  object-class  subtype-of  Signals 

Xprim 

var 

Unit-Stop-S«qusnca 

:  object-class  subtype-of  Signals 

Xprim 

var 

■oisa 

:  object-class  subtype-of  Signals 

Xprim 

var 

Pioceviss-Linoar 

:  object-class  subtype-of  Signals 

Xprim 

var 

Displays  :  object- 

-class  subtype-of  DSP 

var 

Print -Signal 

;  object-class  subtype-of  Displays 

Xprim 

var 

Save-Signal 

:  object-class  subtype-of  Displays 

Xprim 

var 

Graph- 1 -Signal 

:  object-class  subtype-of  Displays 

Xprim 

var 

Graph-2-Signal 

:  object-class  subtype-of  Displays 

Xprim 

var 

Graph-3-Signal 

:  object-class  subtype-of  Displays 

Xprim 

var 

Graph-4-Slgnal 

:  object-class  snbtypa-of  Displays 

Xprim 

var 

Signal-Arithmetic 

:  object -class  subtype-of  DSP 

var 

Signal-Adder 

:  object-class  subtype-of  Signal-Arithmetic 

Xprim 

var 

Signal-Multiplier 

:  object-class  subtype-of  Signal-Arithmetic 

Xprim 

var 

Signal-Subtractor 

:  object-class  subtype-of  Signal-Arithmetic 

Xprim 

var 

Signal-Divider 

:  object-class  subtype-of  Signal-Arithmetic 

Xprim 

var 

Signal-Abs-Dif 

:  object-class  subtype-of  Signal-Arithmetic 

Xprim 

var 

Real-to-Complez 

:  object-class  subtype-of  Signal-Arithmetic 

Xprim 

var 

Complez-to-Real 

;  object-class  subtype-of  Signal-Arithmetic 

Xprim 

var 

Filter-Components 

:  object-class  subtype-of  DSP 

var 

Adder 

:  object-class  subtype-of  Filter-Components 

Xprim 

var 

Delay 

:  object-class  subtype-of  Filter-Components 

Xprim 

var 

Multiplier 

:  object-class  subtype-of  Filter-Components 

Xprim 

var 

Input-Buffer 

:  object-class  subtype-of  Filter-Components 

Xprim 

var 

Output-Buffer 

;  object-class  subtype-of  Filter-Components 

Xprim 

var 

Signal-Processing 

:  object -class  subtype-of  DSP 

var 

Transforms  :  object-class  subtype-of  Signal-Processing 

var 

DPT 

:  object-class  subtype-of  Transforms 

Xprim 

var 

IDFT 

:  object-class  subtype-of  Transforms 

Xprim 

var 

Spectral-Estimation 

;  object-class  subtype-of  Signal-Processing 

var 

Filters  :  object-class  subtype-of  Signal-Processing 

var 

Time-Filter 

:  object-class  subtype-of  Filters  Xprim 

var 

Frequency-Filter 

;  object-class  subtype-of  Filters  Xprim 

X  specific  filters  belong  here 

var 

Filter-Design 

:  object-class  subtype-of  Signal-Processing 

var 

User-Designed-Filter  :  object-class  snbtypa-of  Filter-Design 

Xprim 

XButtervorth,  etc.  filter  designs  belong  here 

var 

Linear-Operations 

:  object-class  subtype-of  Signal-Processing 

var 

Convolution 

:  object-class  subtype-of  Linear-Operations 

Xprim 

var 

Signal -Manipulations 

:  object-class  subtype-of  Signal-Processing 

var 

Pad-Signal 

:  object-class  subtype-of  Signal-Manipulations  Xprim 

var 

Scale-Signal 

:  object-class  subtype-of  Signal-Manipulations  Xprim 

var 

Truncate-Signal 

:  object-class  subtyps-uf  Signal-Manipulations  Xprim 

var 

Windov-Signal 

:  object-class  subtype-of  Signal-Manipulations  Xprim 

var 

Reverse-Signal 

:  object-class  subtype-of  Signal-Manipulations  Xprim 

Figure  5.6  Architect’s  domain  class  code  for  the  DSP  domain 
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X  domain-specific  types 


type  sample-type  ■  real 

type  real-signal-type  ■  seqCsample-type) 

type  complez-sample-type  ■  tnple (real-part:  sample-type, 

imaginary-part :  saiq>le-typa) 
type  complex-signal-type  ■  seq(complez-sample-type) 
type  filter-design-type  ■  tnpleCa:  seq(real),  b:  seq(real)) 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

Xdomain-specific  functions 

function  complez-add(Xl ; complez-sample-type, 

Z2 : complez-sample-type)  :  complez-sample-type  > 

<X1. real-part  *  X2 . real-part ,  XI . iswginary-part  *  X2. imaginary-part > 

function  complez-multiplyCZl ;complez-sample-typo, 

Z2 : complez-sample-type)  :  complex-sample-type  ■ 

<Z1 . real-part  «  X2.real-pa]:^  -  Z1 . imaginary-part  *  X2. imaginary-part, 

XI. real-part  *  X2 . imaginary-part  XI. imaginary-part  •  X2.real-part> 

function  complex-divide (XI : complez-sample-type, 

X2 : complez-sample-type)  :  complez-sample-type  - 
let(sum-sqn  :  real  -  X2. real-part  *  X2. real-part  ♦  X2 . imaginary-part  *  X2. imaginary-part) 
< (XI. real-part  *  X2. real-part  *  XI . imaginary-part  •  X2. imaginary-part)  /  snm-sqn, 

(XI. imaginary-part  •  X2. real-part  -  Xi. real-part  •  X2. imaginary-part)  /  sum-sqn> 

function  complex-of (H;real,  P:real)  :  complex-sample-type  ■ 

<  coerce(M  «  cos(P),  ’single-float), 
coerce(N  •  sia(P),  ’single-float)  > 

function  Magnitnde-of(C: complex-sample-type)  :  real  ■ 

sqrt(C. real-part  «  C. real-part  *  C . imaginary-part  •  C.isMginary-part) 

function  Pbasa-of(C: complez-sample-type)  :  real  ■ 
let (temp: real  >0.0) 

C. real-part  '■  0.0  — >  temp  ■  coerce(atan(C. imaginary-part/C. real-part) , ’single-float) ; 
temp 


Figure  5.7  User-defined  typas  and  functions  for  the  DSP  domain 
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Next,  the  code  to  implement  the  attributes  for  each  component,  specify  the  DSL, 
2md  describe  the  visual  objects  (VSL)  is  created^.  The  code  to  implement  these  portions 
of  the  domain  model  for  the  DFT  component  appears  in  Figures  5.8,  5.9,  and  5.10.  Note 
that  after  the  attributes  (the  DFT  primitive  clciss  there  has  one  attribute)  are  specified  in 
the  attribute  section  of  the  code,  they  are  just  repeated  in  the  other  two  portions.  The 
only  case  in  which  this  repetition  does  not  hold  is  if  a  primitive  class  h*a  attributes  that 
the  user  should  not  be  able  to  change  (for  example,  attributes  that  hold  state  data);  these 
attributes  2ure  prevented  from  being  edited  by  excluding  them  from  the  VSL.  Remember 
that  the  text  above  each  attribute  is  displayed  in  the  window  in  which  the  Application 
Specialist  ctin  change  the  attribute  vtJues. 

var  DFT-COEFFICIEITS  :  iiiap(DFT,  satC&aae-valua-obj)) 
compatad-nsing 
DFT-COEFFICIEITS (x)  -  {} 

"If  this  attribnta  is  sat  to  true,  than  aach  sanpla  of  the  ontput 
sill  ba  dividad  by  tha  nnmbar  of  samplas  in  tha  input." 
var  DFT-SCALE-BY-IIVERSE-I  :  map  (DFT,  boolaan) 
computad-nsing 

DFT-SCtLE-BY-IIVERSE-I(t)  -  falsa _ 

Figure  5.8  Attribute  code  for  the  DFT  primitive  class 


dft  C"dft"  nama 

{[(["scale"  !!  dft-scale-by-invarse-n]  I 

["no  scale"  "!!  dft-scale-by-invarsa-n])]}] 
bnilds  dft. 

Figure  5.9  DFT  portion  of  the  DSL 

We  have  shown  this  code  here  because  we  have  been  using  the  DFT  primitive  class 
as  an  example  throughout  the  description  of  the  population  process.  However,  since  the 
DFT  only  has  one  attribute,  it  is  not  very  interesting.  Therefore,  we  also  show  this  code 
for  the  Sinusoid  primitive  cIms,  which  has  several  attributes,  in  Figures  5.11,  5.12,  smd 
5.13 

In  these  figures  it  is  much  easier  to  see  how  attributes  are  repeated  in  each  portion. 
This  repetition  lends  itself  to  automation.  It  would  be  relatively  easy  to  create  a  tool  in 

^From  Chapter  IV,  DSL  =  Domidn  Specific  L^ulguage  and  VSL  =  Visnalization  Specification  Language. 
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AttribntM  for  dft  ar* 

Icon  : 

Inbol  -  clMa-nnd-nuM; 
clip-icon- labol?  -  falaa; 
bordar-tbicknass  ■  0; 
bitM^4icon-l  ■  dft-1; 
bitaap4icon-a  >  dft-a 
Edit  : 

nana  :  ayabol; 

acala-b;-invaraa-n  :  boolaan 

and; 


Figure  5.10  DFT  portion  of  the  VSL  spec 


▼ar  SIVOSOIO-COEFFICIEITS  :  iBap(SirTS0ID,  aat (naaa-valna-ob j ) ) 
compntad-ttsing 

SiroS0ID-C0EFriCIE«TS(x)  -  {} 

"tba  nnmbar  of  aamplaa  tba  ontpnt  vill  contain" 
var  SIIUSOIO-nmBER-OF-SiMPLES  :  mapCSIlQSOID,  intagar) 
compntad-nsing 

SIIQSOID-nmBER-OF-SANPL£S(z)  -  64 

"this  valna  ia  half  tha  diffaranca  batwaan  tha  maxinnin 
and  ninimnm  aanplaa  in  tha  aignal” 
var  SIIUSOID-AMPLITUDE  :  napCSIlUSOID,  real) 
computad-naing 

SIIUSOIO-iNPLITUDECz)  -  1.0 

"IMPORTAIT;  if  a  fraqnancy  >  0.5  ia  antarad,  aliaaing 
aill  occur  and  a  aignal  with  fraqnancy  <0.5  will  ba  ganaratad." 
var  SIIUSOID-FREQOEICY  :  napCSIlOSOID,  raal) 
computad-uaing 

SIIUSOlD-FREqOEICY(z)  -  0.125 

"tha  phaaa  ahift,  in  radiana" 
var  SIIUSOIO-PHASE-SHIFT  :  aapCSIlUSOIO,  raal) 
computad-naing 

SIItJSOID-PHASE-SHIFT(x)  «  0.0 

"thia  offaat  will  ba  addad  to  ovary  aamplo  in  tha  aignal" 
var  SIlUSOID-tUGIITUDE-OFFSET  :  mapCSIROSOID,  raal) 
computad-uaing 

SIIirS0ID-NA6IITUDE-aFFSET(z)  -  0.0 


Figure  5.11  Attribute  code  for  the  Sinusoid  primitive  class 
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■iaasoid  : :■  ["sinnaoid"  nama 
{[“•  samplaa:"  aiBnaoid-uuBbar-of-saaiplas] 
["anqplitada:''  sinnaoid-aaplitsda] 

["fraquancy:"  aitmaoid-fraqaancy] 

["phaaa  ahift;"  alnaaoid-phaaa-akift] 
["magaitnda-oflaat : "  ainaaoid-aagnitada-off aat] }] 

bailda  ainaaoid. 


Figure  5.12  Sinusoid  portion  of  the  DSL 


attribataa  for  ainaaoid  wa 
Icon  : 

labal  ■  claaa-and-name ; 
clip-icoa-labal?  >  falaa; 
bordar-thicknaaa  ■  0; 
bitmap4icoB-l  ■  ainaaoid-1; 
bitmap4icon-a  >  ainaaoid-a 
Edit  : 

name  :  aymbol; 

nambar-of-aamplea  :  integar; 
amplitada  :  raal; 
fraqaancy  :  raal; 
phaaa-ahift  :  raal; 
magnitada-offaet  :  raal 

and; 


Figure  5.13  Sinusoid  portion  of  the  VSL  spec 


5-19 


which  the  Software  Engineer  would  enter  the  attributes  and  whether  or  not  each  one  is 
allowed  to  be  changed  by  the  Application  Specialist.  The  tool  would  then  generate  this 
code.  As  a  matter  of  fact,  this  tool  should  be  built  to  cover  the  whole  Architect  domain 
implementation  process  (see  Section  6.3). 

The  final  step  in  implementing  the  domain  model  is  to  create  the  code  that  tells  the 
AVSI  where  the  icon  files  are  for  the  different  primitive  classes.  The  portion  of  this  code 
for  the  DFT  primitive  class  is  shown  in  Figure  5.14.  The  actual  icons  are  created  in  the 
during  the  next  Jictivity  (Implement  Primitive  Classes),  but  because  of  the  Architect  file 
conventions  (see  Appendix  C),  it  is  easier  to  specify  this  code  for  the  whole  domain  at  the 
szime  time,  rather  than  2idding  to  this  code  individually  for  each  primitive  class. 


var  dft-1:  any-type  ■  (c«: :raad-bitmap("OSP-TECH-BiSE/dlt. icon-1")) 
var  dft-a:  any-typa  «  (cw: :read-bitmap("DSP-TECH-BASE/dft.icon-8")) 

Figure  5.14  DFT  primitive  class  icon  object  definitions 

5.4-2  Implement  Primitive  Classes.  After  the  domain  model  is  implemented,  the 
the  code  to  implement  the  interface  (inputs  and  outputs),  class  description,  amd  update 
function(s)  for  each  primitive  class  is  created.  The  code  for  the  DFT  primitive  class  appears 
in  Figmre  5.15. 

Due  to  the  form  of  the  Dommn  Analysis  outputs,  the  creation  of  this  code  simply 
involved  converting  pseudo-code  into  REFINE  code.  We  captured  the  component  function¬ 
ality  during  the  Domain  Analysis  process  in  this  fashion  (with  only  one  function,  which  is 
baised  on  transforming  inputs  to  outputs)  because  we  knew  the  form  that  the  domain  im¬ 
plementation  would  taike.  This  is  another  example  of  the  DOACS  knowledge  base  structure 
2Lffecting  the  Domain  Analysis  process. 

The  input/output  type  tell  Architect  what  type  of  data  that  input /output  contains. 
This  type  must  be  one  of  the  basic  REFINE  types  (boolean,  integer,  real,  character,  string, 
and  symbol)  or  one  of  the  user  defined  types  entered  implemented  during  the  Domain 
Implementation  activity. 
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Xinput  s/ontpvt  s 


var  DFT-mPDT-DATA  :  ■•t(iaport-obj)  » 

{set-attrs  (maka-objact(’import-obj) , 

*  import -nama,  'input, 

’ import-category,  'real-signetl, 

'import-type-data,  ’real-signal-type)} 

var  DFT-OBTPDT-DATA  :  set(ezport-obj)  - 

{set-attrs  (make-object Cexport-obj) , 

'export -name,  'ontpnt, 

'export -category,  'complex-signal, 

’ export -type-data ,  ’ complex-signal -type) } 

Xset  description - 

form  set-and-gate-description 

re: :zl-docnmentat ion (find-object (’re: :binding, ’DFT))  <- 
"The  Discrete  Fourier  transform  takes  a  signal  in  the  time  domain  and 
converts  it  to  the  frequence  domain." 

Xupdate  functions - — — - - — - - — - 

function  DFT-UPDATE  (subsystem  :  subsystem-obj , 
the-dft  :  DPT)  • 

format (dsp-debug,  "DFT-DPDATE  on  "s*X",  name(the-dft)) j 

let  (S  :  real-signal-type  ■  get-import ('input,  subsystem,  the-dft), 

0  :  complex-signal-type  >  [] , 
angle  :  real  ■  0.0, 

the-size  :  integer  *  0, 

cn  :  complex-number  ■  <0.0,  0.0>) 

the-size  <-  size(S)  -  1; 

(enumerate  i  from  0  to  the-size  do 
cn. real-part  <-  O.Oj 
cn . imaginary-part  <-  0.0; 

(enumerate  j  from  0  to  the-size  do 

angle  <-  (2  •  pi  •  i  *  j)  /  the-size; 

cn. real-part  <-  coerce  (cn.  real-part  +  S(j'»l)  •  cos  (angle) , ’single-float) ; 
cn. imaginary-part  <-  -1  •  coerce (cn. imaginary-part  + 

S  ( j+1)  •  8in(attgla) , ' single-float) ) ; 
if  DFT-SCALE-BY-IMVERSE-H(the-dft)  then 
cn. real-part  <-  cn. real-part  /  the-size; 
cn . imaginary-part  <-  cn. imaginary-part  /  the-size; 

0  <-  append (0,  cn) 
else 

□  <-  append (0,  cn)); 

set-export (subsystem,  the-dft,  'output,  0) 

var  DFT-DPDATE-FTOCTIOH  :  map (DFT,  symbol) 
computed-using 

DFT-DPDATE-FD>CTIOH(x)  -  'DFT-DPDATE 

Figvire  5.15  DFT  primitive  class  code 
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There  is  only  one  piece  of  information  that  the  Software  Engineer  must  create  dur¬ 
ing  this  whole  domain  implementation  process  (all  the  rest  of  the  needed  information  is 
provided  in  the  domain  analysis  results):  the  category  names  for  the  inputs  and  outputs. 
These  category  names  are  used  by  Architect  during  the  semantics  check  to  ensure  that  two 
connected  components  are  allowed  to  be  coimected.  If  the  category  names  are  not  the  same 
for  a  connected  input  and  output,  then  an  error  message  is  displayed  and  the  apphcation 
cannot  be  executed.  There  are  no  restrictions  on  these  names,  except  that  they  must  con- 
tmn  no  spaces  (they  are  not  case-sensitive).  Therefore,  the  Software  Engineer  can  name 
them  anything  he/she  weints  (hopefully  something  descriptive  of  the  data  they  contain), 
but  the  names  must  be  consistent  across  all  primitive  classes.  In  the  DSP  domain  there  are 
four  categories  of  inputs/outputs:  real-signal,  complex-signal,  sample,  and  filter-design. 

After  the  primitive  implementation  code  is  generated,  the  last  step  is  to  create  the 
primitive  class  icons.  Currently,  these  icons  are  being  generated  using  the  IconEdit  tool 
shown  in  Figure  4.16.  As  stated  in  Section  4.3.2.2,  two  separate  icons  need  to  be  created 
for  each  primitive  class:  one  large  (64x64)  and  one  small  (32x32).  The  large  icons  for  the 
DSP  domain  are  shown  in  Figure  5.16,  which  is  a  screen  capture  of  the  DSP  Technology 
Base  Window. 

5.5  Evaluate  Domain  Development 

The  above  discussions  of  the  first  fom:  activities  accomplished  during  the  Architect 
DSP  implementation  process  were  written  as  if  they  haul  been  done  all  at  once  without  any 
mistadtes;  however,  this  is  not  the  case.  Om  generic  knowledge  base  population  methodol¬ 
ogy  process  weis  designed  to  be  an  iterative  process  (discussed  through-out  Chapter  III);  it 
is  impractical  to  expect  that  these  four  activities  could  be  consistent,  complete,  jmd  correct 
the  first  time  through.  Also,  both  the  domciin  analysis  results  smd  the  domeun  implemen¬ 
tation  should  be  evolved  over  time;  therefore,  the  outputs  of  the  first  four  activities  are 
evaluated  in  this  final  activity.  These  evaluations  feed  back  into  the  other  four  activities 
to  provide  this  evolution. 

In  this  section,  we  will  discuss  the  evciluation  and  evolution  of  the  domain  model 
hierarchy  and  the  testing  of  the  individued  primitives.  The  testing  of  the  domedn  imple- 
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Figure  5.16  The  DSP  Technology  Base  Window 

mentation,  as  specified  in  Section  4.3.3,  v/as  accomplished  by  creating  “simple”  apphca- 
tions  that  contain  only  a  few  primitives  whose  correct  outputs  were  known.  Some  of  these 
applications  are  presented  in  Appendix  B. 


5.5.1  Evolving  the  DSP  Domain  Hierarchy.  As  stated  previously,  the  DSP  do- 
mcun  model  hierarchy  shown  in  Figure  5.4  was  the  first  attempt  at  classifying  the  domain. 
Figure  5.17  shows  the  finail  DSP  domain  model  hierarchy  developed  as  a  peurt  of  this  re¬ 
search  (the  main  differences  will  be  explmned  in  the  following  paragraphs).  It  is  expected 
that  this  hierarchy,  along  with  the  rest  of  the  domain  information,  will  continue  to  develop 
over  time. 

The  changes  made  to  the  DSP  domain  model  hierarchy  were  made  for  three  main 
reasons.  The  first  weis  to  make  the  domain  model  more  complete;  more  Transforms  and 
Signal  Manipulations  components  were  added  for  this  reason.  However,  with  a  complex 
and  evolving  domain  like  DSP,  it  will  not  be  possible  to  add  all  possible  components  to 
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Figure  5.17  Revised  Architect  DSP  domain  hierarchy 

the  model.  The  Domain  Engineer  should  resist  the  temptation  to  add  components  just 
because  they  can  be  added:  only  those  components  that  are  expected  to  be  of  use  should 
be  2uided.  If  a  missing  useful  component  is  identified  later,  it  can  easily  be  eulded. 

The  second  reason  is  that,  as  our  underst^lnding  of  the  DSP  domzun  grew,  we  decided 
to  restructure  the  DSP  model  classes.  The  best  example  of  a  change  for  this  reason  is  the 
restructuring  of  the  filter  portion  of  the  model  hierarchy  (the  lower  right-hand  comer  of 
Figures  5.4  and  5.17.  After  more  research  into  how  filters  were  created,  we  decided  that, 
while  the  structure  in  Figure  5.4  is  a  valid  way  of  ordering  filter  components,  the  structure 
in  Figure  5.17  is  better.  In  this  structure,  an  Application  Specialist  can  create  a  filter 
by  first  choosing  a  generic  time  or  frequency  filter  (which  have  attributes  for  specifying 

*4 

lowpass,  highpass,  banpass,  or  banstop)  and  then  incorporating  one  of  the  standard  filter 
designs,  or  by  choosing  a  specific  pre-designed  filter  (represented  by  “specific  filters”  in 
Figure  5.17).  We  do  not  attempt  to  list  any  pre-designed  filters  here  because  there  are  an 
infinite  number  of  them.  They  should  be  implemented  as  the  need  for  them  is  identified 
(we  did  implement  one,  the  window-lowpass-filter,  to  validate  the  concept).  In  both  model 
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hierarchies,  the  Application  Specialist  can  eilso  create  a  filter  by  using  the  primitives  listed 
vmder  “filter  components”. 

The  third  reason  for  the  changes  between  our  starting  and  current  DSP  domain  model 
hierarchies  is  that  missing  components  were  identified  during  the  domain  implementation 
and  even  during  the  use  of  the  domain  in  Architect  as  application  were  composed.  We 
identified  that  the  input/output  bufifers  under  the  Filter  Components  class  were  needed 
during  the  domain  implementation  phase.  Most  of  the  DSP  components  in  our  model 
have  inputs  amd  outputs  consisting  of  signals,  but  the  components  under  Filter  Compo¬ 
nents  (adder,  delay,  and  multiplier)  have  inputs/outputs  that  consist  of  a  single  sample. 
Therefore,  if  these  components  are  going  to  be  used  with  other  components  (for  example. 
Signals  and  Displays  components),  then  there  must  be  some  intermediate  components  that 
convert  between  these  two  types.  For  this  reason,  the  input/output  buffers  were  added. 
We  did  not  discover  that  the  real-to-complex  and  complex-to-real  components  (under  the 
Signal  Arithmetic  class)  were  needed  until  we  were  2ictually  composing  test  applications. 
Specifically,  we  wanted  to  see  a  graph  of  the  output  of  a  DFT  primitive,  but  this  was  not 
possible  because  the  DFT  primitive  class  outputs  a  complex-signal  while  all  the  Display 
primitive  classes  need  a  resJ-signal  for  their  inputs. 

The  above  paragraphs  describe  the  evolution  of  the  DSP  domain  model  hierarchy 
during  our  thesis  effort.  The  components  defined  in  the  Domain  Analysis  process,  the 
DSP  domain  model  implementation,  and  the  DSP  Architect  primitives  also  evolved  during 
this  time.  The  evolution  of  the  defined  Domain  Aneilysis  components  and  DSP  domain 
model  implementation,  while  significant,  are  not  as  interesting  or  readily  identifiable,  and 
so  will  not  be  discussed  here. 

5.5.2  Testing  Primitives.  Architect  has  a  tool  for  testing  the  behavior  of  prim¬ 
itives,  called  Test-Primitive.  Figure  5.18  shows  this  tool  being  used  to  test  the  Complex- 
To-Real  primitive. 

The  Test-Primitive  function  controls  five  windows.  The  first,  shown  in  the  upper 
right,  is  titled  Test-Primitive  and  displays  the  name  and  icon  of  the  primitive  tmder  test, 
along  with  buttons  to  update  the  primitive  and  exit  this  tool.  The  window  below  this 
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Figure  5.18  The  Test-Primitive  Function 
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one  is  a  text-edit  window  containing  automatically  generated  REFINE  code  in  which  the 
Software  Engineer  enters  the  desired  test-case  inputs  (a  separate  section  is  created  for  each 
input  -  in  this  case  there  is  only  one).  The  window  in  the  lower  left,  titled  Attributes, 
lists  the  current  values  of  the  attributes  for  the  primitive  (in  this  case  there  is  only  one) 
and  allows  them  to  be  changed.  The  Outputs  window,  immediately  above  the  Attributes 
window,  shows  the  outputs  of  the  primitive  (again,  in  this  case  there  is  only  one)  after  it 
has  been  updated.  The  window  behind  this  one,  titled  Inputs,  is  not  necessarily  needed-it 
just  shows  the  current  values  of  the  inputs  as  a  verification  that  the  inputs  entered  in  the 
text-edit  window  were  indeed  correctly  interpreted  and  assigned  to  the  appropriate  inputs. 

The  Test-Primitive  function  is  used  by  entering  the  desired  test-case  attribute  and 
input  values,  choosing  “Update”  firom  the  Test-Primitive  window,  and  then  comparing  the 
outputs  to  the  expected  test-case  outputs.  Assuming  these  steps  are  accomplished  cor¬ 
rectly,  a  difference  between  the  listed  outputs  and  the  expected  test-case  outputs  demon¬ 
strates  ein  error  in  the  primitive.  The  absence  of  an  error  cannot  be  demonstrated;  there¬ 
fore,  the  software  engineer  shovdd  use  good  testing  techniques  in  choosing  the  test  cases  to 
be  examined  (boundary  testing,  decision-point  testing,  etc.). 

Once  edl  the  primitives  have  been  tested  separately  (as  described  above  for  the  DPT 
primitive),  the  interface  between  the  primitives  needs  to  be  tested.  This  was  done  by 
creating  some  small  applications  whose  expected  behavior  was  already  identified.  Examples 
of  two  of  these  applications  can  be  found  in  Appendix  B.  Some  of  these  applications  were 
validated  by  calculating  the  expected  outputs  for  specific  inputs  by  hand,  while  others 
were  validated  by  building  a  simil2u:  application  in  Khoros  and  MatLab  and  comparing  the 
results. 

5.6  Architect  Problems  that  Affect  the  Use  and  Implementation  of  the  DSP  Domain 

Architect  is  an  evolving  system;  the  AFIT  KBSE  group  continues  to  identify  defi¬ 
ciencies  in  and  new  composition  methods  for  Architect.  This  section  discusses  four  of  the 
biggest  problems  with  Architect  that  have  ein  impact  on  the  implementation  2md  use  of 
the  DSP  domain  in  Architect. 
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5.6.1  “State”  Attributes.  The  OCU  model  (described  in  Section  4.2.1)  lists 
severaJ  parts  of  a  component,  but  Architect  does  not  implement  them  all  separately. 
Specifically,  OCU  component  attributes,  statejdata,  and  constants  aure  ail  implemented 
in  Architect  as  primitive  attributes,  with  no  method  to  distinguish  between  them.  This 
combination  of  attributes  and  state^ata,  in  particular,  can  cause  problems  in  DSP  ap¬ 
plications  (or  amy  other  domadn,  for  that  matter).  The  problem  is  that  OCU  component 
statejdata  shotdd  be  set  to  some  specific  vadue  before  eaich  execution  (initiadized),  while 
OCU  component  attributes  are  set  by  the  user  amd  not  initiadized.  Architect  primitive 
attributes,  however,  cannot  be  initiadized.  This  can  result  in  effectively  non-deterministic 
behavior,  since  the  staurting  state  of  the  primitives  in  Architect  cannot  be  guauramteed  to 
be  the  saune  between  each  execution. 

An  example  of  a  DSP  primitive  that  demonstrates  this  problem  is  the  delay  primitive 
(imder  the  Filter  Components  in  Figure  5.4).  Dtiring  eaudi  update,  this  primitive  tadces  in 
a  signad  saunple  amd  returns  the  sample  tadcen  in  during  the  previous  update.  To  hold 
this  value  in  between  updates,  the  delay  primitive  has  an  attribute  cadled  last-sample 
(it  is  not  listed  in  the  VSL  specification  file,  and  therefore  camnot  be  modified  by  the 
Application  Speciadist).  Since  there  is  no  previous  update  to  the  first  update,  the  delay 
primitive  should  return  a  zero  for  that  first  update.  To  implement  this,  the  starting 
vadue  of  last-saunple  is  zero.  This  works  for  the  first  execution  of  am  application;  however, 
on  subsequent  executions  of  that  saune  application,  the  staurting  vadue  of  last-sample  is 
whatever  it  happened  to  be  set  to  dming  the  lawt  update  of  the  primitive  in  the  previous 
execution:  there  is  no  automatic  method  to  reset  it  to  zero!  To  work  aroimd  this  problem, 
the  Application  Speciadist  must  remember  to  reset  this  attribute  to  zero  for  every  delay 
primitive  in  the  application  before  every  execution,  or  the  output  for  that  execution  will 
be  invadid.  Another  work-axoimd  is  to  add  a  SetState  cadi  for  eamh  delay  primitive  in  its 
pau'ent  subsystem’s  update  algorithm,  but  this  camnot  currently  be  done  through  the  visual 
system  (AVSI).  The  problem  is  discussed  in  the  next  section. 

5.6.2  Subsystem  Update  Algorithm.  The  AVSI  does  not  currently  provide  a 
method  for  entering  all  the  allowable  statements  into  the  update  adgorithms  of  subsystems 
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and  applications.  Specifically,  SetState,  SetPunction  statements  cannot  be  enterea;  also, 
there  is  no  method  to  enter  primitive  output  values  into  the  expressions  of  “if”  and  “while” 
statements.  The  current  work-aroimd  is  to  create  the  application,  save  the  application, 
edit  the  application  save  file  to  add  these  statements,  and  then  reload  the  application. 

An  example  of  this  limitation  affecting  our  research  surfaced  in  an  application  con¬ 
taining  Filter  Components  primitives.  In  general,  such  an  application  has  a  subsystem 
that  contains  sm  input-buffer,  some  nvunber  of  adders,  delays,  and  multipliers,  and  an 
output-buffer.  The  input-buffer  takes  in  a  signal  and  sends  it  out  one  sample  at  a  time 
to  the  2uider8,  delays,  and  multipliers.  The  output-buffer  collects  the  resulting  samples 
and  combines  them  into  a  new  signal.  While  other  components  transform  a  signal  in 
one  update,  this  particular  process  takes  several  updates  of  each  primitive  to  completely 
transform  the  signal,  requiring  a  “while”  loop  statement  in  that  subsystem’s  update  algo¬ 
rithm.  The  “while”  loop  can  be  added  through  AVSI,  but  the  problem  occurs  when  the 
conditional  expression  for  the  loop  is  built.  To  tell  the  subsystem  when  the  last  sample 
of  the  signal  has  been  sent  out,  the  input-buffer  has  an  output  called  “done”,  which  is 
set  to  true  during  the  update  when  the  last  sample  has  been  sent  out.  At  this  time,  the 
loop  should  terminate  2md  a  few  more  updates  should  be  called  to  the  other  primitives  in 
the  subsystem  to  process  this  last  sample.  However,  the  “done”  output  caimot  be  added 
to  the  loop  condition  in  AVSI;  it  must  be  entered  by  editing  the  application’s  saved  file. 
This  is  a  problem  because  it  requires  the  Application  Specialist  to  have  knowledge  about 
how  Architect  stores  saved  applications,  and  requires  him/her  to  save,  edit,  and  load  the 
application  before  he/she  can  simulate  its  execution. 

5.6.3  Export  Values.  A  related  problem  to  the  “state”  attributes  problem  is 
that  export  values  are  imdefined  at  the  beginning  of  the  first  execution  of  an  application, 
but  on  subsequent  executions  they  start  out  with  whatever  values  they  were  assigned  last 
during  the  previous  execution.  This  causes  effectively  non-deterministic  behavior  in  any 
application  that  has  a  loop  (or  primitives  being  updated  out  of  order).  The  Filter  Com¬ 
ponents  primitives  example  from  the  last  section  demonstrates  this  problem;  the  adders, 
delays,  and  multipliers  in  the  subsystem  described  above  are  almost  always  composed  into 
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a  looping  structure.  An  example  of  this  is  shown  in  Figure  5.19.  This  configuration  shows 
an  accumulator  in  which  every  sample  of  the  output  signal  will  be  the  sum  of  all  the  pre¬ 
vious  samples  of  the  input  signal.  The  first  time  this  subsystem  is  updated,  the  export 
value  associated  with  the  delay  output  is  undefined,  which  the  adder  knows  to  interpret 
as  a  zero.  Every  time  thereafter,  even  if  the  delay  last-sample  attribute  is  reset  to  zero, 
the  export  value  associated  with  that  output  will  still  be  set  to  whatever  value  was  output 
on  the  previous  update,  resulting  in  the  total  sum  of  the  previous  signal  being  added  in 
to  the  current  signal.  This  is  not  desired.  The  current  work-aroimd  for  this  problem  is 
to  reload  the  application  each  and  every  time  before  execution;  when  an  application  is 
reloaded,  all  the  export  values  are  set  to  the  REFINE  “undefined”  vzJue  (in  other  words, 
they  are  initialized). 


adder 


delay 

Figure  5.19  An  accumulator 


5.6.4  Coefficients  and  Constants.  Although  coefficients  are  implemented  for 
primitives  in  Architect,  their  purpose  is  not  well-defined  and  there  is  no  clear  method  for 
using  them  or  chzmging  their  values.  Therefore,  we  did  not  implement  any  coefficients 
for  DSP  primitives.  Whenever  a  case  came  up  during  the  domain  implementation  phase 
where  we  felt  that  a  coefficient  would  be  the  logical  choice,  we  used  attributes  instead.  Also, 
Architect  does  not  have  a  method  for  implementing  the  constants  in  the  OCU  model;  they 
must  also  be  implemented  as  attributes. 
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5. 7  Summary 

This  chapter  described  the  DSP  domain  implementation  accomplished  as  a  part  of 
this  thesis  effort.  This  implementation  was  saccessful  (as  demonstrated  by  the  applica¬ 
tions  shown  in  Appendix  B),  and  is  included  in  the  current  version  of  Architect.  We 
pointed  out  that  McCain’s  domain  analysis  approach  fits  well  into  our  generic  knowledge 
base  population  method  smd  produces  outputs  that  can  easily  be  entered  into  Architect’s 
Technology  Base.  We  also  identified  several  cases  where  the  domain  analysis  was  not  as 
independent  of  the  specific  DOACS  (in  this  case,  Architect)  as  we  had  envisioned  in  our 
generic  population  methodology,  both  because  this  was  a  small-scale  implementation  effort 
(only  one  DOACS),  as  well  as  the  fact  that  the  state-of-the-art  for  domain  analysis  is  not 
advanced  enough  to  capture  all  types  of  useful  information  in  a  standard  format.  Finally, 
we  discussed  four  problems  in  Architect  that  hinder  implementation  and  use  of  a  domain. 
These  issues  will  appear  in  the  next  chapter  as  recommendations  for  future  research. 
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VI.  Conclusions  and  Recommendations 


6.1  Results  of  This  Research 

From  Chapter  I  (Section  1.2),  the  problem  description  for  this  research  was: 

Investigate  eind  implement  a  method  to  populate  the  Technology  Base  (knowl¬ 
edge  base)  in  Architect  and  demonstrate  that  a  more  substantial  domain  can 
be  implemented  in  this  system. 

We  were  successful  in  achieving  these  objectives.  First  we  defined  and  made  generaliza¬ 
tions  about  application  composition  systems,  which  resulted  in  G-DOACS  (Figure  3.1). 
To  our  knowledge,  this  generalization  had  not  been  attempted  before.  We  then  used  the 
G-DOACS  concept  to  help  define  emd  generalize  about  methods  to  add  domain  informa¬ 
tion  to  DOACSs,  which  led  to  the  development  of  our  generic  knowledge  base  population 
methodology  (Figure  3.4)  This  methodology  is  mostly  a  synthesis  of  three  established 
methods  (5,  32,  25),  but  it  does  present  some  new  concepts  such  as  keeping  the  domain 
analysis  phase  independent  from  the  requirements  of  a  particular  DOACS,  incorporating 
^Veusable  applications”  back  into  the  domain  model  and  domsun  implementation,  and  pro¬ 
viding  a  direct  and  integrated  method  for  evaluation  and  feedback.  We  then  instantiated 
this  generic  methodology  for  a  specific  DOACS:  Architect  (Figtire  4.8).  This  step  pro¬ 
duced  a  formalized  method  to  implement  domains  in  Architect,  meeting  the  first  objective 
of  our  problem  statement.  To  substantiate  this  method,  we  analyzed  the  DSP  domain, 
implemented  it  in  Architect,  and  validated  this  implementation  by  testing  the  primitives 
and  creating  applications  whose  correct  behaviors  were  known  in  advance.  This  process 
accomplished  the  second  objective  in  our  problem  statement. 

6.2  Conclusions 

Our  conclusions  concerning  the  generic  knowledge  base  population  methodology  we 
developed  are: 

‘These  first  two  steps  were  developed  jointly  with  Sandy. 
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•  Our  generic  knowledge  base  population  methodology  is  valid.  We  instantiated  it  and 
used  that  instantiation  to  implement  the  DSP  domain.  Also,  Sandy  instamtiated  the 
same  process  for  his  research  in  (35). 

•  Our  generic  knowledge  base  population  methodology  is  indeed  “generic”.  It  is  not 
dependent  on  a  particular  domain  walysis  appro2ich  nor  on  a  particulsu*  DOACS; 
rather,  it  was  designed  to  generalize  them.  We  designed  this  methodology  so  that 
it  can  be  instantiated  for  any  current  object-oriented  domain  analysis  approach  and 
DOACS,  and  hope  it  is  able  to  accommodate  future  ones. 

•  Domain  analysis  should  be  done  as  independently  from  the  requirements  of  a  partic¬ 
ular  DOACS  as  possible;  however,  complete  independence  is  not  currently  possible 
(as  discussed  in  Section  5.3.1).  Our  generic  population  methodology  specifies  de¬ 
coupling  of  the  analysis  and  implementation  phases,  but  the  state-of-the-eirt  is  not 
yet  advanced  enough  to  completely  accomplish  this  goal,  because  there  are  no  stan¬ 
dardized  methods  and  formats  to  capture  all  required  domain  knowledge.  A  simple 
example  is  adding  the  domain  visualization  step  to  McCsdn’s  domain  analysis  process 
(see  Section  5.3.2)-as  with  all  current  domain  analysis  approaches,  it  did  not  provide 
for  capturing  all  the  information  that  any  DOACS  would  need.  Also,  we  captured 
the  DSP  domain  using  an  architecture  very  similar  to  the  one  used  in  Architect  (the 
OCU  model).  This  provided  a  significant  time  savings  since  conversion  between  ar¬ 
chitectures  is  not  currently  well-imderstood;  however,  it  also  constrained  the  domain 
zmalysis  process  with  another  Architect  requirement.  As  domain  analysis,  domain 
implementation,  and  application  composition  in  general  become  more  understood, 
we  believe  that  this  division  will  be  a  natural  result,  much  like  the  division  between 
the  front  and  ba^rk  ends  of  a  compiler  (discussed  in  Section  3.3). 

•  The  domain  analysis  and  domain  implementation  steps  of  our  process  are  not  one¬ 
time  affairs.  It  is  impractical  to  expect  that  a  process  as  complicated  as  domain 
analysis  or  domain  implementation  can  be  done  all  at  once  and  be  consistent  and 
complete.  Also,  new  information  (both  about  the  domain  as  well  as  domain  anal¬ 
ysis/implementation  methods)  will  always  surface  requiring  changes;  therefore  the 


6-2 


domain  implementation,  as  well  as  the  domiun  ansdysis  results,  must  evolve  over 
time.  Our  generic  methodology  provides  for  this  evolution. 

The  conclusions  we  arrived  at  concerning  Architect  are 

•  Architect  is  capable  of  composing  applications  in  more  sophisticated  domains.  As 
stated  in  Chapter  I,  before  this  research  effort,  only  two  relatively  simple  domains  had 
been  implemented  in  Architect.  One  of  the  goals  of  this  research  was  to  implement  a 
domzun  that  had  more  features  (more  interface  types,  wider  scope,  larger  nxunber  of 
primitives,  etc)-this  goal  wja  met  by  implementing  the  DSP  domain  and  composing 
applications  in  that  domain.  There  are  some  problems  with  Architect  that  limit  the 
DSP  domain  implementation,  however.  These  problems  were  discussed  in  Section  5.6. 

•  Implementing  a  domain  in  Architect  is  a  relatively  easy  and  straightforward  t2isk. 
Additionally,  this  process  is  well-defined  and  is  accomplished  in  the  same  manner  for 
every  domain.  If  the  domsiin  analysis  is  accomplished  correctly,  domain  implemen¬ 
tation  is  simply  an  exercise  of  converting  the  domain  information  firom  the  format 
used  in  the  domain  smalysis  process  to  the  format  required  by  Architect.  This  type 
of  conversion  process  lends  itself  to  automation,  as  discussed  in  the  following  section. 

6.3  Recommendations  for  Further  Research 

Several  ideas  for  further  research  were  identified  during  our  thesis  effort.  The  more 
important  ones  are  listed  below.  The  first  few  are  more  or  less  independent  of  Architect; 
the  last  few  make  recommendations  about  including  already  research  technologies  into 
Architect.  Appendix  D  listr  more  recommendations  for  additions  to  Architect  whose  scope 
was  not  broad  enough  to  be  listed  here. 

•  More  research  must  be  done  in  the  area  of  domain  2uialysis/domain  implementation. 
As  stated  above,  this  technology  is  still  in  its  early  stages  and  needs  more  study 
before  the  application  composition  philosophy  can  become  widespread.  Specifically, 
the  type  and  method  of  capture  of  the  information  that  needs  to  be  collected  dmring 
the  domain  analysis  phase  to  support  the  domain  implementation  in  many  different 
systems  needs  to  be  better  defined. 
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•  Reseaxch  should  be  conducted  into  converting  domain  information  from  the  knowl¬ 
edge  base  of  one  DOACS  into  the  knowledge  base  of  another.  This  is  based  on  the 
idea  that  dommn  2malysis  should  only  be  done  once  for  a  domain,  not  once  every 
time  that  dom2dn  is  implemented  in  another  DOACS.  Based  on  our  research  and 
that  of  Sandy  (35),  converting  domain  information  from  APTAS  to  Architect  should 
be  possible.  One  step  beyond  converting  information  between  DOACSs  is  to  build 
a  system  that  captures  domain  information  in  a  DOACS  independent  form.  This 
system  could  then  be  used  to  supply  domain  to  different  DOACSs. 

•  Methods  to  vahdate  domains  should  be  studied.  In  Architect,  while  the  validation 
of  individual  primitives  is  well-defined  (using  the  Test  Primitive  tool) ,  validating  the 
domain  as  a  whole  is  not  so  well-defined.  Research  in  this  area  may  result  in  a  “Test 
Domain”  tool,  but  as  a  minimum  it  should  result  in  a  formalized  method  with  clejur 
and  concise  guidelines. 

•  Collecting  and  'mplementing  domain-specific  semantic  information  should  be  investi¬ 
gated.  Architect  performs  semantic  checks  on  applications  but  currently  only  checks 
constraints  from  the  OCU  model.  Domain-specific  semantic  checks  should  be  added; 
however,  how  to  collect,  implement,  and  use  this  domain-specific  sememtic  informa¬ 
tion  is  not  yet  well-understood. 

•  As  stated  above  in  oiu:  conclusions,  domain  implementations  are  not  static;  they  need 
to  evolve.  Part  of  this  evolution  may  include  chemging  the  functionsility  of  a  primitive. 
When  a  primitive  chamges,  however,  all  the  previously  created  applications  need  to 
be  chzinged  also.  Research  needs  to  be  conducted  on  what  to  do  with  previously 
created  applications  when  a  primitive  is  changed. 

•  The  implementation  of  domain-specific  architectures  into  Architect  should  be  stud¬ 
ied.  Currently,  Architect  has  only  one  architecture  (the  OCU  model).  Additional 
eirchitectures,  or  the  ability  of  the  Software  Engineer  to  create  a  new  architectmre  for 
each  domain,  should  be  studied  for  addition  to  Architect. 

•  The  Architect  domain  implementation  method  formalized  as  a  part  of  this  research 
(Chapter  IV)  needs  to  be  updated  with  the  database  work  accomplished  by  Cecil  and 
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Fullenkamp  (7)  and  the  event-driven  domain  implementation  work  accomplished  by 
Waggoner  (41).  As  stated  in  Section  1-3  there  were  several  research  efforts  involving 
chcinges  to  Architect  that  were  accomplished  currently  to  our  research;  due  to  the 
intractability  of  attempting  to  keep  all  these  research  efforts  up-to-date  with  each 
other,  they  were  done  independently  for  the  most  part^.  The  results  of  the  two 
research  efforts  listed  above  made  changes  to  Architect  that  affect  our  research; 
therefore,  when  all  these  independent  changes  are  integrated,  our  Architect  domain 
implementation  method  will  have  to  be  updated.  We  say  “updated”  because  the 
changes  should  be  minor,  except  for  the  need  to  collect  timing  information  during 
the  domain  analysis  process. 

•  Additional  composition  methods  should  be  studied  for  possible  implementation  in 
Architect.  Currently  Architect  has  only  one  composition  method:  the  Application 
Specialist  chooses  primitives  and  connects  them  together.  Another  possible  com¬ 
position  method  might  be  for  the  Application  Specialist  to  identify  the  problem  to 
be  solved  by  specifying  parameters  and  answering  questions,  then  having  Architect 
automatically  compose  the  application.  The  filter  design  portion  of  the  DSP  domain 
would  be  a  good  validation  area  for  this  research. 

•  Now  that  this  research  has  formedized  the  process  of  domain  implementation  in  Ar¬ 
chitect,  research  should  be  conducted  into  automating  this  process.  Bsised  on  our 
research  effort,  we  conclude  that  such  a  tool  could  be  easily  created.  For  example, 
the  Software  Engineer  could  enter  the  information  required  for  domaiin  implementa¬ 
tion  in  Architect  (see  Appendix  A)  in  a  high-level  form  (perhaps  by  creating  a  visuzd 
object  model);  this  automated  tool  would  transform  this  information  and  add  it  to 
A’’chitect’s  Technology  Base.  Such  a  tool  would  save  time  emd  reduce  errors  in  the 
domaiin  implementation  process  (for  example,  as  it  stands  now  the  softwaure  engineer 
must  specify  the  attributes  of  each  primitive  three  times  in  three  different  formats; 
this  takes  time  aind  increases  the  potential  for  errors). 

^As  stated  in  Section  1.3,  the  one  research  effort  we  did  completely  incorporate  into  our  work  was 
Cossentine’s  visualization  research  (9). 
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After  accomplishing  this  automation,  research  should  be  conducted  into  implement¬ 
ing  domains  in  Architect  using  automated  domfun  analysis  tools  (one  such  tool  is 
OAKS  (10),  described  in  Section  3.3).  This  research  should  investigate  using  an 
automated  domain  analysis  tool  to  input  domain  information  into  Architect's  Tech¬ 
nology  Base  directly,  as  well  as  tying  an  automated  domain  analysis  tool  to  the 
domain  implementation  tool  discussed  above. 

While  Architect  as  it  currently  exists  is  a  fuUy  functional  DO  ACS,  there  are  several 
features  that  would  add  to  the  system’s  capabilities.  The  features  identified  as  a  part  of 
this  research  effort  that  require  further  study  are  listed  in  Appendix  D. 

6.4  Concluding  Remarks 

Current  software  development  methods  are  not  capable  of  handling  cmrent,  let  alone 
future,  software  requirements.  Software  engineers  cannot  continue  to  treat  each  develop>- 
ment  effort  as  a  separate  and  imique  problem.  Methodologies  that  focus  on  automated 
reuse  of  domain,  software  engineering,  and  problem  solving  information  need  to  become 
the  rule  in  software  development  organizations.  Technologies,  like  application  composi¬ 
tion,  that  implement  these  methodologies  will  revolutionize  the  way  in  which  software  is 
created  so  that  development  can  keep  up  with  demand.  This  research  has  contributed  to 
this  future  of  automated,  standsurdized  software  development  by  generalizing  about  appli¬ 
cation  composition  systems,  creating  a  methodology  to  populate  applications  composition 
systems,  and  giving  an  example  of  a  specific  population  process  for  a  particuleu:  application 
composition  system. 
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Appendix  A.  Domain  Information  Needed  for  Architect 

This  appendix  summarizes  the  abstract  domain  information  needed  to  implement  a 
domain  in  Architect  and  the  form  it  takes  in  that  implementation.  This  information  must 
be  contained  in  the  outputs  of  the  domain  analysis  activity. 

1.  A  Description  of  the  Domain:  includes  domain  assumptions  and  domain  design  in¬ 
formation,  among  other  things.  Basically,  include  any  information  that  the  Software 
Engineer  will  need  to  understand  the  domain  analysis  outputs.  The  Software  En¬ 
gineer  will  use  this  description,  along  with  domain  implementation  information,  to 
develop  the  domain  description  that  is  included  with  the  implementation  in  Archi¬ 
tect. 

2.  Domain  structure:  a  “tree-like”  organization  of  reusable  components  (the  leaves  of 
the  tree  -  they  will  become  primitives  when  implemented)  and  generalization  cleisses 
(branches  in  the  tree).  A  name  must  be  assigned  to  each  node  in  the  tree.  An 
example  of  such  a  domain  structure  is  shown  in  Figure  5.17. 

3.  Interface  types:  each  type  of  information  that  will  be  passed  between  the  reusable 
components  must  be  defined.  For  each,  a  name  and  description  of  what  data  it 
contains  must  be  defined.  An  example  in  the  DSP  domain  is  the  interf^lce  type 
called  complex-sign2d.  The  complex-signal  type  consists  of  a  sequence  of  psurs  of 
real  numbers  where  each  element  of  the  sequence  represents  one  sample,  the  first 
re*il  nvunber  of  each  element  represents  the  real  part  of  a  complex  number,  emd 
the  second  resd  number  of  each  element  represents  the  imaginary  part  of  the  seune 
complex  number. 

4.  Reusable  component  definitions:  for  eeich  reusable  component  listed  above,  the  fol¬ 
lowing  must  be  defined: 

•  Description:  text  describing  the  ptupose  and  use  of  this  component 

•  Attributes:  name,  type,  allowable  values,  whether  or  not  it  should  be  user- 
editable,  default  value,  2uid  a  text  description 

•  CoeflScients:  name,  allowable  values,  and  default  value 
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•  Inputs/Outputs:  name  and  interface  type 

•  Icon(s):  for  Architect,  these  icons  must  be  bitmaps 

•  Update  function:  for  implementation  in  Architect,  this  function  must  be  speci¬ 
fied  in  Refine 

This  short  list  is  all  the  information  needed  in  the  domain  analysis  outputs  to  im¬ 
plement  a  domain  in  Architect. 
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Appendix  B.  Digital  Signal  Processing  Examples  in  Architect 


This  appendix  will  consist  of  a  two  examples  of  DSP  applications.  The  first  is  a 
conical  DSP  application  called  a  moving  average,  shown  in  Figme  B.l.  This  particular 
application  is  a  four-sum  moving  average:  each  sample  of  the  output  is  the  average  of  the 
current  output  along  with  the  three  previous  samples.  The  multiplier  primitive  (looks  like 
a  triangle)  has  a  value  of  0.25  for  its  multiply  value.  The  input  signal  loaded  from  a  file  was 
generated  by  a  previous  application  that  simply  added  a  sinusoid  with  some  noise.  Note 
that  this  application  displays  two  signals:  the  original  input  (shown  in  Figure  B.2)  and 
the  output  after  going  through  the  fovir-sum  moving  average  part  (shown  in  Figme  B.3). 


Figure  B.l  A  Four-Sum  Moving  Average 
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Figure  B.2  The  Input  to  the  Four-Sum  Moving  Average 
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Figure  B.3  The  Output  from  the  Four-Sum  Moving  Average 
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The  second  application,  called  Window-Demo,  shows  why  windowing  should  be  used 
before  a  Fourier  transform  is  applied.  For  this  application,  shown  in  Figure  B.4,  a  sinusoid 
is  transformed  in  two  different  ways  and  then  both  are  displayed.  The  lower  path  takes 
the  input  sinusoid  through  a  Fourier  transform  and  a  complex-to-real  conversion  (the  DFT 
primitive  outputs  a  complex  signal,  but  the  graph2-signal  primitive  can  only  show  resJ 
signals);  the  output  from  this  path  is  shown  in  Figiure  B.5.  The  upper  path  takes  the  input 
sinusoid  through  a  window,  and  then  through  a  Fourier  transform  and  a  complex-to-real 
conversion  just  like  the  lower  path;  the  output  from  this  path  is  shown  in  Figxure  B.6.  Note 
that  this  output  is  much  closer  to  the  canonical  representation  of  a  sinusoid  after  a  Fotirier 
transform  has  been  applied,  which  is  the  purpose  of  windowing  a  signal. 
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Figure  B.4  The  Window-Demo  Application 
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Figxire  B.5  The  Fourier  TYansform  without  Windowing 
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Figure  B.6  The  Fourier  Transform  with  Windowing 
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Appendix  C.  File  Conventions  for  Architect 

This  appendix  contains  the  file  conventions  currently  being  used  for  Architect. 

Although  all  the  code  to  implement  a  domidn  in  the  Technology  Base  could  be 
entered  into  one  file,  this  file  would  be  confusing,  making  changes  difficxilt.  To  alleviate 
this  problem,  file  conventions  are  being  ised  to  manage  this  information.  The  following 
files  contain  the  domain  information  for  Architect's  Technology  Base: 

1.  dm-<domain-name>.re:  this  file  contains  the  domain-specific  types,  domain-specific 
functions,  domain  class  declarations  (with  structure),  and  the  domain  description. 
This  file  includes  the  code  in  Figures  5.6  and  5.7. 

2.  <primitive-name>.re:  one  file  for  each  primitive.  This  file  contains  the  primitive 
inputs  and  outputs,  attributes,  coefi5cients,  description,  and  update  function.  This 
file  includes  the  code  in  Figures  5.8  and  5.15  for  the  DFT  primitive. 

3.  <primitive-name>.icon-l  and  <primitive-neime>.icon-s:  one  each  for  every  primi¬ 
tive.  These  fiJies  contain  the  bitmaps  that  are  used  to  create  the  primitive  icons  in 
Architect.  Ciurently,  these  files  eure  created  using  the  OpenWindows  IconEdit  tool. 

4.  gram-<domain-name>.re:  this  file  contains  the  DSL  grammar.  A  production  is 
created  for  each  primitive  as  shown  in  Figure  5.9  for  the  DFT  primitive.  All  attributes 
for  a  primitive  are  listed  except  for  “state”  attributes  that  should  be  initialized  to 
their  default  values  (specified  in  the  previous  file)  every  time  the  a  primitive  of  that 
class  is  loaded  with  an  application. 

5.  vsl-<domain-name>.re:  this  file  contains  the  domain  visual  specification  that  is 
parsed  in  through  Architect’s  VSL  grammar.  A  section  is  entered  for  each  primitive; 
in  this  section,  the  attributes  that  should  be  editable  by  the  Application  Specialist 
are  entered  (the  un-editable  attributes  are  not  entered).  This  file  includes  the  code 
in  Figure  5.10  for  the  DFT  primitive. 

6.  var-<domain-name>.re:  this  file  contains  two  lines  for  each  primitive  that  simply 
create  the  icon  objects  for  each  primitive.  This  file  includes  the  code  in  Figiure  5.10 
for  the  DFT  and  Sinusoid  primitives. 
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The  above  file  conventions  2Lre  just  one  of  a  possible  set  of  ways  to  organize  the  code 
to  implement  a  domain  in  Refine.  Comparing  these  file  descriptions  with  the  information 
in  the  previous  appendix,  it  can  be  seen  that  the  first  three  types  of  files  contain  the  bulk 
of  the  information,  the  rest  mostly  repeat  the  information  defined  in  these  first  three. 
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Appendix  D.  Future  Recommended  Features  for  Architect 

This  appendix  summarizes  the  features  identified  during  this  research  effort  that  we 
feel  should  be  studied  for  incorporation  into  Architect. 

1.  There  2ure  cxurently  no  boimds  on  the  value  that  can  be  assigned  to  primitive  at¬ 
tributes  other  than  the  standard  type  checking.  It  would  be  useful  if  the  Software 
Engineer  could  add  additional  bounds  on  the  2Jlowable  values  of  an  attribute;  for 
example,  a  primitive  may  have  two  attributes  such  that  the  value  of  one  must  be 
less  than  the  value  of  the  other.  The  implementation  of  further  restrictions  should 
be  studied. 

2.  Although  user-defined  types  (like  real-signal- type)  can  be  used  to  define  primitive 
attributes  and  input /outputs,  they  caimot  be  accessed  in  the  if/while  statement  con¬ 
ditioned  part.  Currently,  only  real,  integer,  string,  and  booleem  variables  zure  allowed 
in  these  statements.  The  ability  to  access  user-defined  types  in  these  statements 
should  be  added. 

3.  Integration  of  dommn-independent  primitives  into  Architect  should  be  studied.  For 
example,  the  two  DSP  primitives  that  convert  real  numbers  to/from  complex  niimbers 
should  not  be  DSP-specific;  they  should  be  provided  to  any  domain. 

4.  The  ability  to  take  a  subsystem  and  add  it  to  the  technology  base  window  with  the 
primitives  should  be  added.  This  would  allow  the  Application  Specialist  to  add  the 
functionality  of  such  a  subsystem  to  applications  without  recreating  and  revalidating 
it  every  time. 

5.  OCU  component  attributes,  constamts,  auid  current^tate  variables  au:e  adl  imple¬ 
mented  in  Architect  as  attributes;  this  causes  problems  in  the  DSP  domaiin  (discussed 
in  Section  5.6).  These  three  vauriables  should  be  implemented  differently  from  eaich 
other,  or  a  method  to  distinguish  between  them  should  be  added. 

6.  Several  of  the  DSP  primitives  implemented  a»  a  part  of  this  research  have  the  saime 
functionality,  the  only  difference  is  that  they  have  a  different  number  of  inputs. 
This  is  because  all  inputs  must  be  connected  before  applications  cam  be  executed; 
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however  some  components  defined  in  the  domain  analysis  do  not  have  a  fixed  number 
of  inputs.  One  example  in  the  DSP  domain  is  the  four  graph-X-signal,  where  X  is 
1,  2,  3,  or  4.  If  Architect  had  the  ability  to  have  optional  inputs  on  primitives, 
then  only  one  graph  primitive  would  have  had  to  be  implemented.  Also,  the  ability 
to  have  N-input  primitives  (where  the  Application  Specialist  specifies  N)  would  be 
useful.  An  example  in  the  DSP  domain  where  this  would  be  useful  is  the  adderX 
primitives;  only  three  of  them  were  implemented  because  there  are  no  bounds  on  X 
for  this  primitive. 

7.  Some  attribute  types  lend  themselves  to  enumerated  t3rpes;  however.  Architect  does 
not  have  the  capability  to  handle  these  enumerated  types.  An  example  in  the  DSP 
domain  where  this  would  be  useful  is  the  real-to-complex  primitive.  This  primitive 
has  an  attribute  called  conversion-type  which  tells  the  primitive  what  method  to 
use  in  converting  the  signal;  there  are  four  types:  real,  imaginary,  magnitude,  2uid 
phase.  When  we  implemented  this  primitive,  we  had  to  implement  it  as  a  symbol 
and  indicate  in  the  attribute  description  that  there  were  only  four  allowable  values; 
an  enumerated  type  would  have  been  much  better 

8.  When  making  primitive  connections  intemEd  to  a  subsystem,  if  an  output  is  connected 
to  an  input  in  that  subsystem,  there  is  nothing  to  show  whether  or  not  it  is  also 
connected  to  another  input  outside  the  subsystem.  This  problem  hides  important 
information  from  the  Application  Specialist. 

9.  Architect  has  the  ability  to  use  generically  specified  applications  (called  generics)  as 
described  in  (3)  and  (33);  however,  their  purpose  is  not  well-imderstood  and  AVSI 
does  not  support  them.  Hence,  further  research  would  be  valuable. 
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Appendix  E.  REFINE  Code  Listings  for  Architect 

The  Refine  source  code  for  Architect  and  the  implemented  DSP  domain  may  be 
obtained,  upon  request,  from: 

Maj  Paul  Bailor 
AFIT/ENG 
2950  P  Street 

Wright-Patterson  AFB,  OH  45433-7765 

(513)255-9263 
DSN  785-9263 
email:  pbailorClafit.af.mil 
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